Vous pouvez transmettre l'état via une URL d'action lorsque vous envoyez des actions par e-mail pour réinitialiser un mot de passe ou valider l'adresse e-mail d'un utilisateur. L'utilisateur peut ainsi être redirigé vers l'application une fois l'action terminée. De plus, vous pouvez spécifier si le lien d'action par e-mail doit être géré directement à partir d'une application mobile lorsqu'elle est installée, plutôt que sur une page Web.
Cela peut être extrêmement utile dans les scénarios courants suivants :
Un utilisateur qui n'est pas connecté tente d'accéder à un contenu qui nécessite une connexion. Toutefois, il a peut-être oublié son mot de passe et déclenche donc le flux de réinitialisation du mot de passe. À la fin du flux, l'utilisateur s'attend à revenir à la section de l'application à laquelle il essayait d'accéder.
Une application ne peut proposer l'accès qu'aux comptes validés. Par exemple, une application de newsletter peut demander à l'utilisateur de valider son adresse e-mail avant de s'abonner. L'utilisateur suit le flux de validation par e-mail et s'attend à être redirigé vers l'application pour finaliser son abonnement.
En général, lorsqu'un utilisateur lance un flux de réinitialisation de mot de passe ou de validation par e-mail dans une application Apple, il s'attend à ce que le flux se termine dans l'application. La possibilité de transmettre l'état via une URL d'action rend cela possible.
La possibilité de transmettre l'état via une URL d'action est une fonctionnalité puissante fournie par Firebase Auth, qui peut améliorer considérablement l'expérience utilisateur.
Transmettre l'état/l'URL d'action dans les actions par e-mail
Pour transmettre une URL d'action de manière sécurisée, le domaine de l'URL doit être ajouté à la liste d'autorisation dans la console Firebase. Pour ce faire, accédez à la section Authentication (Authentification) et ajoutez ce domaine à la liste des Authorized domains (Domaines autorisés) sous l'onglet Sign-in method (Méthode de connexion), s'il n'y figure pas déjà.
Une instance ActionCodeSettings doit être fournie lors de l'envoi d'un e-mail de réinitialisation de mot de passe ou d'un e-mail de validation. Cette interface utilise les paramètres suivants :
| Paramètre | Type | Description | |||
|---|---|---|---|---|---|
url |
Chaîne | Définit le lien (état/URL d'action) qui a différentes significations selon le contexte :
|
|||
iOSBundleId |
Chaîne | Définit l'ID de bundle. Le lien tente de s'ouvrir dans une application Apple si elle est installée. L'application doit être enregistrée dans la console. Si aucun ID de bundle n'est fourni, la valeur de ce champ est définie sur l'ID de bundle du bundle principal de l'application. | |||
androidPackageName |
Chaîne | Définit le nom du package Android. Le lien tente de s'ouvrir dans une application Android si elle est installée. | |||
androidInstallApp |
booléen | Indique s'il faut installer l'application Android si l'appareil la prend en charge et qu'elle n'est pas déjà installée. Si ce champ est fourni sans a packageName, une erreur s'affiche pour indiquer que packageName doit être fourni avec ce champ. | |||
androidMinimumVersion |
Chaîne | Version minimale de l'application compatible avec ce flux. Si minimumVersion est spécifié et qu'une version antérieure de l'application est installée, l'utilisateur est redirigé vers le Play Store pour mettre à niveau l'application. L'application Android doit être enregistrée dans la console. | |||
handleCodeInApp |
booléen | Indique si le lien d'action par e-mail doit être ouvert d'abord dans une application mobile ou dans un lien Web. La valeur par défaut est "false" (inactif). Si la valeur est "true" (actif), le lien du code d'action est envoyé en tant que lien universel ou lien vers une application Android, et il est ouvert par l'application si elle est installée. Si la valeur est "false" (inactif), le code est d'abord envoyé au widget Web, puis, si l'utilisateur clique sur "Continuer", il est redirigé vers l'application si elle est installée. | |||
dynamicLinkDomain |
Chaîne | (Obsolète, utilisez `linkDomain`) Définit le domaine (ou sous-domaine) de lien dynamique à utiliser pour le lien actuel s'il doit être ouvert à l'aide de Firebase Dynamic Links. Comme plusieurs domaines de liens dynamiques peuvent être configurés par projet, ce champ permet d'en choisir un explicitement. Si aucun n'est fourni, le premier domaine est utilisé par défaut. | linkDomain |
Chaîne | Domaine Firebase Hosting personnalisé facultatif à utiliser lorsque le lien doit être ouvert via une application mobile spécifiée. Le domaine doit être configuré dans Firebase Hosting et appartenir au projet. Il ne peut pas s'agir d'un domaine Hosting par défaut (`web.app` ou `firebaseapp.com`). Il remplace le paramètre obsolète `dynamicLinkDomain`. |
L'exemple suivant montre comment envoyer un lien de validation par e-mail qui s'ouvre d'abord dans une application mobile en tant que lien Firebase Dynamic Link à l'aide du domaine de lien dynamique personnalisé example.page.link (application iOS com.example.ios ou application Android com.example.android, où l'application s'installe si elle n'est pas déjà installée et la version minimale est 12). Le lien profond contient la charge utile de l'URL d'action https://www.example.com/?email=user@example.com.
final user = FirebaseAuth.instance.currentUser;
final actionCodeSettings = ActionCodeSettings(
url: "http://www.example.com/verify?email=${user?.email}",
iOSBundleId: "com.example.ios",
androidPackageName: "com.example.android",
);
await user?.sendEmailVerification(actionCodeSettings);
Configurer Firebase Dynamic Links
Firebase Auth utilise Firebase Dynamic Links lors de l'envoi d'un lien destiné à être ouvert dans une application mobile. Pour utiliser cette fonctionnalité, vous devez configurer Dynamic Links dans la console Firebase.
Activer Firebase Dynamic Links :
Dans la console Firebase, ouvrez la section Dynamic Links (Liens dynamiques).
Si vous n'avez pas encore accepté les conditions d'utilisation de Dynamic Links et créé un domaine Dynamic Links, faites-le maintenant.
Si vous avez déjà créé un domaine Dynamic Links, notez-le. Un domaine Dynamic Links se présente généralement comme suit :
example.page.link
Vous aurez besoin de cette valeur lorsque vous configurerez votre application Apple ou Android pour intercepter le lien entrant.
Configurer des applications Android :
- Si vous prévoyez de gérer ces liens à partir de votre application Android, vous devez spécifier le nom du package Android dans les paramètres du projet de la console Firebase. De plus, vous devez fournir les empreintes SHA-1 et SHA-256 du certificat d'application.
- Vous devez également configurer le filtre d'intent pour le lien profond dans votre fichier AndroidManifest.xml.
- Pour en savoir plus, consultez les instructions concernant la réception de liens dynamiques Android.
Configurer des applications Apple :
- Si vous prévoyez de gérer ces liens à partir de votre application, vous devez spécifier l'ID de bundle dans les paramètres du projet de la console Firebase. De plus, vous devez spécifier l'ID App Store et l'ID d'équipe de développeur Apple.
- Vous devez également configurer le domaine de lien universel FDL en tant que domaine associé dans les fonctionnalités de votre application.
- Si vous prévoyez de distribuer votre application sur les versions 8 et antérieures d'iOS, vous devez définir votre ID de bundle comme schéma personnalisé pour les URL entrantes.
- Pour en savoir plus, consultez les instructions concernant la réception de liens dynamiques sur les plates-formes Apple.
Gérer les actions par e-mail dans une application Web
Vous pouvez spécifier si vous souhaitez gérer d'abord le lien du code d'action à partir d'une application Web, puis rediriger l'utilisateur vers une autre page Web ou application mobile une fois l'opération terminée, à condition que l'application mobile soit disponible.
Pour ce faire, définissez handleCodeInApp sur false dans l'objet ActionCodeSettings. Bien qu'un ID de bundle ou un nom de package Android ne soient pas obligatoires, les fournir permet à l'utilisateur d'être redirigé vers l'application spécifiée une fois le code d'action par e-mail terminé.
L'URL Web utilisée ici est celle configurée dans la section des modèles d'actions par e-mail. Une URL par défaut est provisionnée pour tous les projets. Pour en savoir plus sur la personnalisation du gestionnaire d'actions par e-mail, consultez Personnaliser les gestionnaires d'e-mails.
Dans ce cas, le lien dans le paramètre de requête continueURL sera
un lien FDL dont la charge utile est le URL spécifié dans l'objet ActionCodeSettings. Bien que vous puissiez intercepter et gérer le lien entrant à partir de votre application sans aucune dépendance supplémentaire, nous vous recommandons d'utiliser la bibliothèque cliente FDL pour analyser le lien profond.
Lors de la gestion d'actions par e-mail telles que la validation par e-mail, le code d'action du paramètre de requête oobCode doit être analysé à partir du lien profond, puis appliqué via applyActionCode pour que la modification prenne effet (c'est-à-dire que l'e-mail soit validé).
Gérer les actions par e-mail dans une application mobile
Vous pouvez spécifier si vous souhaitez gérer d'abord le lien du code d'action dans votre application mobile, à condition qu'elle soit installée. Avec les applications Android, vous pouvez également spécifier via androidInstallApp que l'application doit être installée si l'appareil la prend en charge et qu'elle n'est pas déjà installée.
Si l'utilisateur clique sur le lien à partir d'un appareil qui ne prend pas en charge l'application mobile, il est ouvert à partir d'une page Web.
Pour ce faire, définissez handleCodeInApp sur true dans l'objet ActionCodeSettings. Vous devez également spécifier le nom du package Android ou l'ID de bundle de l'application mobile.L'URL Web de remplacement utilisée ici, lorsqu'aucune application mobile n'est disponible, est celle configurée dans la section des modèles d'actions par e-mail. Une URL par défaut est provisionnée pour tous les projets. Pour en savoir plus sur
la personnalisation du gestionnaire d'actions par e-mail, consultez
Personnaliser les gestionnaires d'e-mails.
Dans ce cas, le lien de l'application mobile envoyé à l'utilisateur sera un lien FDL dont la charge utile est l'URL du code d'action, configurée dans la console, avec les paramètres de requête oobCode, mode, apiKey et continueUrl. Ce dernier sera l'URL d'origine spécifiée dans l'objet ActionCodeSettings. Bien que vous puissiez intercepter et gérer le lien entrant à partir de votre application sans aucune dépendance supplémentaire, nous vous recommandons d'utiliser la bibliothèque cliente FDL pour analyser le lien profond. Le code d'action peut
être appliqué directement à partir d'une application mobile, de la même manière que dans
le flux Web décrit dans la section
Personnaliser les gestionnaires d'e-mails.
Lors de la gestion d'actions par e-mail telles que la validation par e-mail, le code d'action du paramètre de requête oobCode doit être analysé à partir du lien profond, puis appliqué via applyActionCode pour que la modification prenne effet (c'est-à-dire que l'e-mail soit validé).