Passer au contenu principal
Pour personnaliser les modèles de courriel, vous devez configurer un fournisseur de courriel SMTP externe. Les modèles de courriel ne sont pas offerts lorsque vous utilisez le fournisseur de courriel intégré d’Auth0.

​
Personnaliser les modèles de courriel

Pour personnaliser un modèle de courriel :
  1. Accédez à Dashboard > Image de marque > Modèles de courriel.
  2. Dans la liste déroulante Template, sélectionnez le modèle de courriel que vous souhaitez mettre à jour.
  3. Sur la page du modèle de courriel, mettez à jour les champs que vous souhaitez personnaliser. Les champs From address, Objet, Rediriger vers et Message prennent en charge la syntaxe Liquid. Pour en savoir plus, consultez Syntaxe Liquid prise en charge.
  4. Cliquez sur Save pour enregistrer vos modifications, sur Try pour les tester ou sur Reset pour les rétablir.

​
Adresse de l’expéditeur

Le champ Adresse de l’expéditeur définit l’adresse courriel que les utilisateurs voient comme adresse d’envoi lorsqu’ils reçoivent un courriel d’Auth0. S’il n’est pas défini, les courriels utilisent l’adresse courriel du champ De configuré pour votre fournisseur de courriel. Lorsque vous définissez le champ Adresse de l’expéditeur, vous devez configurer deux formes d’authentification des courriels pour permettre à Auth0 d’envoyer des courriels signés numériquement en votre nom :
  • Sender Policy Framework (SPF), qui autorise des adresses IP précises à envoyer des courriels à partir d’un domaine
  • DomainKeys Identified Mail (DKIM), qui signe les courriels de façon cryptographique afin que les serveurs de messagerie puissent vérifier qu’ils ont bien été envoyés depuis le domaine indiqué
Sans SPF ni DKIM configurés, les courriels pourraient ne pas être livrés, être bloqués par les filtres antipourriel, ou afficher « On Behalf Of » et révéler l’expéditeur (votre fournisseur de courriel) en plus de l’adresse de l’expéditeur. Pour configurer SPF et DKIM, vous devez créer des enregistrements TXT pour votre domaine. Les valeurs des enregistrements TXT et les autres détails du processus varient, alors suivez les instructions de votre fournisseur de courriel pour cette configuration. En général, l’enregistrement TXT pour SPF doit avoir le nom d’hôte défini sur @ ou laissé vide, et la valeur v=spf1 include:<YOUR_PROVIDER_SPF_DOMAIN> -all. L’enregistrement TXT pour DKIM doit avoir le nom d’hôte défini sur le domaine que vous utilisez pour envoyer des courriels, et la valeur définie sur la signature DKIM que vous générez avec votre fournisseur.

​
Objet

Le champ Objet définit l’objet du courriel. S’il n’est pas défini, Auth0 remplit automatiquement l’objet selon le type de courriel.

​
Message

Le champ Message définit le contenu HTML du corps du message. Chaque modèle comprend un corps de message par défaut, que vous pouvez modifier ou supprimer entièrement pour rédiger le vôtre.

​
Durée de vie de l’URL et Rediriger vers

Les modèles de courriel qui incluent un lien (Courriel de vérification (lien), Changer le mot de passe (lien) et Courriel de compte bloqué) comportent deux champs supplémentaires pour gérer ces liens :
  • Le champ Durée de vie de l’URL définit combien de temps un lien reste valide avant d’expirer. Par défaut, cette durée est de 432 000 secondes (cinq jours).
  • Le champ Rediriger vers définit l’URL vers laquelle un utilisateur est redirigé après avoir effectué l’action associée au lien inclus.
Universal Login ignore actuellement la valeur du champ Rediriger vers dans le modèle Réinitialisation du mot de passe et redirige plutôt vers la route de connexion par défaut ou une page d’erreur.Pour personnaliser l’URL Rediriger vers pour la réinitialisation du mot de passe lorsque vous utilisez Universal Login, utilisez api.transaction.setResultURL() à partir du déclencheur Actions post-challenge
Deux paramètres de requête sont ajoutés à l’URL Rediriger vers :
  • success, défini à true ou false, indique si l’action a réussi
  • message, défini à une description supplémentaire du résultat, comme « L’accès a expiré. » ou « Votre courriel a été vérifié. Vous pouvez continuer à utiliser l’application. »
Si vous avez des problèmes avec l’emplacement des paramètres de requête dans les URL Rediriger vers pour les applications monopages (SPA), la solution de contournement suivante pourrait vous aider.
La RFC 3986 définit l’ordre attendu d’une URL comme scheme|authority|path|query|fragment. Cependant, les frameworks SPA (comme Angular) s’attendent généralement à des URL au format scheme|authority|path|fragment|query, où la requête se trouve après le fragment.Cela peut entraîner un problème avec l’emplacement des paramètres de requête dans les URL Rediriger vers. Si l’URL Rediriger vers de votre SPA est http://localhost:3000/#/register, l’utilisateur est redirigé vers http://localhost:3000/?exampleParameter=exampleValue#/register au lieu de http://localhost:3000/#/register?exampleParameter=exampleValue.Pour contourner cette limitation des frameworks SPA, vous pouvez :
  1. Ajouter une URL côté serveur comme URL Rediriger vers avec un paramètre route qui enregistre la route SPA pour la redirection. Par exemple, http://localhost:3000/register?route=register.
  2. Créer un contrôleur de route côté serveur qui lit route et les autres paramètres de l’URL, redirige vers la route SPA spécifiée dans le paramètre route et ajoute les autres paramètres reçus d’Auth0. Par exemple : 
    var express = require('express');
var router = express.Router();
// Pour lire les paramètres des chaînes de requête et les convertir en chaîne :
var qs = require('qs');

router.get('/register', function(req, res, next) {
    // Récupérer le paramètre de route qui contient la route
    // côté client de la SPA vers laquelle l’utilisateur doit être redirigé.
    var route = req.query.route;

    // Supprimer route des paramètres de requête.
    delete req.query.route;

    // Envoyer une redirection 302 vers la route attendue.
    res.redirect('http://localhost:3000/#/' + route + '?' +  qs.stringify(req.query));
});

module.exports = router;

​
Tester les modèles mis à jour

Pour tester, cliquez sur Essayer, entrez une adresse courriel valide que vous pouvez consulter, puis choisissez le bon type de connexion. Auth0 envoie le courriel pour une application par défaut qui porte le même nom que votre locataire (et non le nom convivial de votre locataire). Pour tester les modèles pour différentes applications, créez un utilisateur de test afin de suivre les flux pertinents. Vous pouvez déclencher manuellement des courriels de vérification pour des applications et des utilisateurs précis à l’aide du point de terminaison Envoyer un courriel de vérification de l’adresse courriel de la Management API.

​
Exemples de cas d’utilisation de la personnalisation

La personnalisation des modèles de courriel permet de répondre à de nombreux cas d’utilisation. Par exemple :
Vous pouvez configurer différentes URL Rediriger vers selon le nom de votre application. Par exemple :
{% if application.name == 'JWT.io' %}
    https://jwt.io
{% else %}
    https://auth0.com
{% endif %}
Comme le nom de l’application est encodé pour des raisons de sécurité, utilisez une valeur encodée (surtout si le nom de votre application contient un caractère qui change une fois encodé). Par exemple, utilisez My%20App au lieu de My App.
À l’aide de Liquid, vous pouvez utiliser le paramètre request_language pour récupérer le paramètre de langue à partir de la valeur de l’en-tête ou, à défaut, utiliser le paramètre de langue du navigateur de l’utilisateur.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 %}
Vous pouvez aussi utiliser la propriété user_metadata.lang pour adapter le contenu selon la langue préférée de l’utilisateur. Par exemple, vous pouvez utiliser une Action pour définir la propriété user_metadata.lang, puis lire le paramètre user_metadata.lang dans vos modèles de courriel afin d’envoyer des courriels dans la langue appropriée.
Pour un contrôle plus fin, vous pouvez envoyer des courriels en dehors de leurs flux de travail standard et créer des tickets (des URL générées pour des actions de flux de travail par courriel, comme les réinitialisations de mot de passe) à l’aide du Management API. Les points de terminaison de courriel et de ticket du Management API comprennent des paramètres supplémentaires qui vous permettent de personnaliser leur comportement. Pour en savoir plus, consultez Personnaliser la gestion des courriels et des tickets avec le Management API.