Nous avons fait des recherches pendant de nombreuses heures déjà.
La première solution qui apparaît partout (d'autres questions StackExchange également) consiste à utiliser un service tiers SendGrid.com et parfois en conjonction avec Zapier, mais ce n'est pas l'approche que nous voulons mettre en œuvre.
Pour l'envoi sans tiers au milieu, la première solution qui semblait viable était "Firebase Triggers", qui a été annoncée à la Google I/O 2014 mais n'a jamais vu le jour et semble avoir été fusionné dans Google Cloud Functions qui est toujours en phase alpha.
Je suis presque sûr d'avoir vu la solution il y a presque un an dans un lien sur le blog de FireBase, mais le seul post qui semble avoir existé sur ce sujet est maintenant vide .
Nous n'avons jamais travaillé auparavant avec GCP, mais notre logique nous dit que ce problème devrait être résolu (à l'intérieur de Google) en utilisant une autre API existante de GCP, et la API de messagerie est apparemment la bonne, mais il semble qu'il n'y ait aucun moyen pour notre Firebase Web App d'effectuer la requête.
Quelqu'un (de préférence avec une expérience de GCP) pourrait-il expliquer quelle est la situation ici, et comment Google s'attend à ce que ses développeurs FireBase envoient des e-mails à leurs clients ?
2 votes
Pour une version actualisée de cet article de blog, voir : cloud.google.fr/solutions/mobile/
2 votes
Firebase ne dispose pas d'un support intégré pour l'envoi d'un courrier électronique spécifié par le développeur. En ce sens, il n'y a pas non plus d'attente sur la façon dont une application envoie des e-mails à ses utilisateurs. Une façon de le faire serait d'utiliser le moteur d'application comme indiqué dans l'article de blog que vous avez mentionné. Mais il existe de nombreuses autres façons d'accomplir la même chose.
0 votes
Merci @FrankvanPuffelen, nous développons une WebApp, donc... nous apprécierions un tel lien pour une approche WebApp s'il existe...
1 votes
@davidtaubmann En fait, vous pouvez suivre le tutoriel partagé par FrankvanPuffelen en commençant par "Adding backend logic using App Engine". Vous créez un projet dans Android Studio mais vous ne travaillez que dans la partie module AppEngine, c'est-à-dire que vous laissez "intact" le module Android app.
0 votes
@frank-van-puffelen et 3371862, si je comprends bien le lien mentionné, la procédure fait une demande au moteur d'application à partir de l'application elle-même, et non à partir de firebase, ce qui signifie que dans un environnement d'applications Web, la demande d'email serait faite par le client-navigateur directement au moteur d'application... Ne serait-ce pas un énorme risque de sécurité ? Et si non... S'il vous plaît expliquer pourquoi pas ...
0 votes
@davidtaubmann Le lien montre comment configurer et développer une servlet dans App Engine qui se connecte à la base de données Firebase et installe un listener : lorsque le listener est déclenché, la servlet envoie un mail. Le servlet est normalement appelé par une tâche cron configurée dans le projet App Engine. Il est possible d'appeler la servlet depuis un navigateur via l'URL de la servlet, mais cela ne doit être utilisé que pour des tests. Cependant, il pourrait effectivement être appelé par quelqu'un d'autre (connaissant l'URL), et je ne suis pas sûr pour le moment si nous pouvons le sécuriser, je dois me plonger dans la doc. A suivre.
0 votes
Suite... Mon commentaire ci-dessus (le 6 mars) visait à indiquer que l'écouteur est déclenché lorsque des données sont ajoutées/modifiées dans la base de données Firebase, indépendamment du type de front-end qui a ajouté/modifié les données (une application Android, une application Web ou même la console Firebase). En d'autres termes, cela fonctionne parfaitement dans votre cas avec une WebApp.
0 votes
@davidtaubmann Oui, vous pouvez sécuriser la tâche cron, cf. cloud.google.com/appengine/docs/standard/java/config/