Personnaliser les modèles de courriels

Les utilisateurs verront l’adresse courriel en tant qu’expéditeur dans le champ Adresse de provenance lorsqu’ils recevront un courriel d’Auth0. Si vous ne configurez pas le champ Adresse de provenance pour un modèle de courriel, Auth0 utilisera, dans le champ provenance, l’adresse courriel configurée pour votre Fournisseur de courriel.

Le champ adresse de provenance prend en charge toutes les variables courantes pour les modèles, mais voici les plus fréquemment utilisées :

• application.name

• friendly_name (pour le nom amical défini du locataire)

Vous pouvez utiliser ces variables pour définir le nom d’affichage de l’adresse de provenance de manière à ce qu’il soit en rapport avec l’application à laquelle l’utilisateur s’est inscrit. Par exemple, le champ pourrait afficher {{ application.name }} <support@fabrikamcorp.com>, au lieu de <support@fabrikamcorp.com>.

Vous devez ajouter les enregistrements DNS du Sender Policy Framework (Cadre de politique d’expéditeur) (SPF) (pour en apprendre davantage, lisez Sender Policy Framework [SPF] sur Wikipédia) et du DomainKeys Identified Mail (pour en apprendre davantage, lisez DomainKeys Identified Mail (DKIM) sur Wikipédia) dans le fichier de zone de votre domaine afin de permettre à Auth0 d’envoyer des courriels signés numériquement en votre nom. Sans ces enregistrements, les courriels risquent de se retrouver dans les dossiers de courriels indésirables de vos utilisateurs. En outre, vos utilisateurs peuvent voir l’élément suivant comme une adresse de provenance

MyApp support@mail128-21.atl41.mandrillapp.com on behalf of MyApp support@fabrikamcorp.com

Configuration du SPF (cadre de politique de l’expéditeur)

Vous pouvez configurer le SPF en ajoutant un enregistrement TXT au fichier de votre zone domaine. Vous devez définir le nom d’hôte sur @, ou le laisser vide, selon le fournisseur. La valeur de l’enregistrement doit ressembler à ce qui suit :

"v=spf1 include:spf.mandrillapp.com -all"

Si vous avez déjà un enregistrement SPF, vous pouvez simplement ajouter include:spf.mandrillapp.com à l’enregistrement existant.

Configuration du DKIM

Configurez le DKIM en ajoutant un enregistrement TXT au fichier de zone de votre domaine. Ce domaine doit être celui que vous utilisez pour envoyer des courriels. Par exemple, si vous utilisez Mandrill, vous allez devoir définir le nom d’hôte de cet enregistrement comme mandrill._domainkey et la valeur comme :

v=DKIM1; k=rsa; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB;

Le champ Objet prend en charge toutes les variables courantes pour les modèles, y compris :

• application.name

• user.email (et d’autres propriétés de l’objet user)

Si le champ Objet est vide, Auth0 remplira automatiquement ce texte en fonction du type de courriel que vous envoyez. Par exemple, une ligne d’objet pourrait être « Vérifiez votre courriel ».

Ligne d’objet multilingue

La langue sélectionnée par l’utilisateur peut être stockée dans user.user_metadata et la syntaxe Liquid utilisée pour le champ Objet.

Par exemple :

{% assign language = request_language %}
  {% if language %}
    {% assign language = request_language | slice: 0,2 %}
  {% endif%}
{% if language == 'es' %}
  Cuenta de Example: bloqueada
{% elsif language == 'de' %}
  Ihr Example wurde gesperrt
{% elsif language == 'fr' %}
  Compte Example bloqué
{% elsif language == 'ja' %}
  Example アカウントがブロックされました
{% elsif language == 'pt' %}
  Conta da Example bloqueada
{% elsif language == 'zh' %}
  Example　帐户被阻止
{% else %}
  Example account blocked
{% endif %}

Le courriel de vérification, le courriel de changement de mot de passe et le courriel de compte bloqué contiennent des liens permettant aux utilisateurs de vérifier leur adresse courriel lors de l’inscription, de confirmer leur changement de mot de passe ou de débloquer un compte bloqué.

Vous pouvez modifier le délai d’expiration de ce lien pour des raisons de sécurité. Par défaut, le délai d’expiration est de 432 000 secondes (cinq jours).

Si les utilisateurs cliquent sur un lien expiré et qu’une URL de redirection est configurée, ils seront redirigés vers l’URL de redirection configurée. Le texte suivant sera ajouté à la chaîne de requête :

http://myapplication.com/my_page/?email=john%contoso.com&message=Access%20expired.&success=false

L’URL de redirection est une destination optionnelle vers laquelle l’utilisateur est redirigé après que l’action pertinente (vérification de compte, réinitialisation du mot de passe, déblocage de compte) a été effectuée.

Avec l’expérience classique de connexion universelle, vous pouvez fournir une URL vers laquelle les utilisateurs sont redirigés après la réinitialisation de leur mot de passe. Auth0 envoie un indicateur desuccess et un message à l’URL. Pour en savoir plus sur ces deux paramètres, voir Description des modèles de courriels.

Avec la nouvelle expérience de connexion universelle, Auth0 redirige les utilisateurs vers le chemin de connexion par défaut lorsque l’utilisateur parvient à réinitialiser son mot de passe. Au cas contraire, Auth0 gère les erreurs dans le cadre du flux de connexion universelle et ignore l’URL de redirection fournie dans le modèle de courriel.

Les trois variables suivantes sont les seules disponibles sur l’URL de redirection

• application.name (ou son synonyme client.name)

• application.clientID

• application.callback_domain (ou son synonyme client.callback_domain)

La variable application.callback_domain contiendra l’origine de la première URL répertoriée dans la liste des URL de rappel autorisée de l’application. Cela vous permet de rediriger les utilisateurs vers un chemin de l’application qui a déclenché l’action en utilisant une syntaxe semblable à celle-ci :

{{ application.callback_domain }}/result_page

Notez que même si la variable s’appelle callback_domain, il s’agit en réalité d’une origine et elle inclut donc le protocole en plus du domaine, par exemple https://myapp.com.

Si votre application contient plusieurs URL de rappel autorisées et configurées, Auth0 utilisera la première URL répertoriée. Vous pouvez également fournir une origine par défaut en utilisant la syntaxe Liquid :

{{ application.callback_domain | default: "https://my-default-domain.com" }}/result_page

URL de redirection dynamique

En fonction du nom de votre application, vous pouvez configurer différentes URL de redirection. Par exemple :

{% if application.name == 'JWT.io' %} https://jwt.io {% else %} https://auth0.com {% endif %}

Étant donné que le nom de l’application est encodé pour des raisons de sécurité, vous devez toujours utiliser une valeur encodée (surtout si le nom de votre application contient un caractère qui change une fois encodé). Par exemple, vous allez vouloir utiliser My%20App au lieu de My App.

Pour les applications web à page unique (SPA), l’URL de redirection peut contenir le hash et le chemin pour un état ou une vue en particulier dans l’application, suivis des paramètres du chemin. Cela peut engendrer le problème suivant avec l’URL de redirection :

http://localhost:3000/#/register

Ce qui entraînera la redirection de l’utilisateur vers l’URL suivante :

http://localhost:3000/?supportSignUp=true
  &supportForgotPassword=true
  &email=john.doe%40exampleco.com
  &message=Your%20email%20was%20verified.%20You%20can%20continue%20using%20the%20application.
  &success=true#/register

Ceci est décrit par les normes Internet (pour en apprendre davantage, lisez la spécification RFC 3986 de l’Internet Engineering Task Force) qui définissent l’ordre attendu d’une URL comme suit scheme|authority|path|query|fragment. Cependant, les cadres d’applications SPA (comme Angular) attendent généralement des URL au format scheme|authority|path|fragment|query(avec les paramètres de la chaîne de requête à la fin). Cela pousse l’application à ne pas entrer dans l’état attendu. Par exemple, avec l’URL susmentionnée, l’application sera dirigée vers / au lieu de /#/register (registre).

Pour contourner cette limitation des cadres d’applications SPA, il est recommandé d’utiliser une URL de rappel côté serveur comme l’URL de redirection avec un paramètre de chemin qui préserve le chemin de l’application SPA pour la redirection. Une fois dans cette URL côté serveur, il suffit de rediriger vers le chemin de l’application Web à page unique enregistrée dans le paramètre de chemin avec le reste de la chaîne de requête.

1. Ajoutez une URL côté serveur comme URL de redirection avec un paramètre de route qui enregistre le chemin de l’application à page unique (SPA) pour la redirection. http://localhost:3001/register?route=register

2. Créez un contrôleur de chemin côté serveur qui lit le chemin et les autres paramètres de l’URL, puis redirige vers la route de l’application Web monopage indiquée dans le paramètre de chemin. N’oubliez pas d’ajouter les autres paramètres reçus d’Auth0.

   var express = require('express');
   var router = express.Router();
   var qs = require('qs'); // to read query string params and stringify them
   
   router.get('/register', function(req, res, next) {
     var route = req.query.route; // retrieve the route param that contains the SPA client side route user needs to be redirected to.
   
     delete req.query.route; // remove it from query params.
     res.redirect('http://localhost:3000/#/' + route + '?' +  qs.stringify(req.query)); // Send a 302 redirect for the expected route
   });
   
   module.exports = router;

   Was this helpful?

   Yes /No

Les corps de message contiennent du contenu HTML et la syntaxe Liquid est la syntaxe de modélisation à utiliser qui est actuellement prise en charge. Vous pouvez utiliser toutes les variables courantes, ainsi que les variables définies dans chaque modèle individuel.

Modèles de courriels multilingues

Vous pouvez utiliser la syntaxe Liquid conjointement avec la propriétéuser_metadata.lang de l’objet utilisateur pour modifier le contenu en fonction de la langue préférée de l’utilisateur. Par exemple, vous pouvez utiliser une action pour définir la propriété user_metadata.langsurit pour l’italien. Vous devez définir la propriété de langue au moyen d’une action ou autrement.

Déboguer les variables du modèle Liquid

Pour vous aider dans le développement de vos modèles, nous avons ajouté une balise {% debug %} Liquid personnalisée qui affiche un résumé des variables de modèle disponibles pour votre modèle lors de son rendu. N’oubliez pas de supprimer cette balise de tous les modèles en « direct ».