Skip to main content
Les Rules s’exécutent dans le cadre d’un pipeline où des artefacts d’authentification sont générés, comme décrit dans Bonnes pratiques relatives à l’anatomie des bases de données personnalisées. Par conséquent, une Rule activée s’exécute pour chaque opération de connexion (interactive ou non), chaque authentification silencieuse et chaque fois qu’un associé aux identifiants de l’utilisateur est généré pour un appel d’API. Cela signifie que, même dans des déploiements de petite envergure, les performances peuvent poser problème, et ce problème ne fera que s’accentuer à mesure que le déploiement prend de l’ampleur.

​
Évitez les exécutions inutiles

Privilégiez une exécution fondée sur une logique conditionnelle. Par exemple, pour exécuter une Rule uniquement pour certaines applications, vérifiez un clientID précis ou des valeurs précises de clientMetadata — en particulier si vous vérifiez une seule valeur de clientMetadata commune à plusieurs applications. L’utilisation de clientMetadata peut aussi faciliter l’ajout de nouvelles applications (ainsi que la lecture du code de la Rule), surtout si vous avez un grand nombre d’applications définies, en réduisant les modifications de code ou les valeurs de configuration requises d’un environnement à l’autre. Les métadonnées d’une application peuvent être définies manuellement dans le en accédant à Application Settings > Advanced Settings > Application Metadata ou de façon programmatique à l’aide de la d’Auth0 et de son point de terminaison Update a client endpoint.

​
Terminez dès que possible

Pour des performances optimales, rédigez des Rules qui se terminent le plus tôt possible. Par exemple, si une Rule comporte trois vérifications pour déterminer si elle doit s’exécuter, utilisez la première vérification pour éliminer la majorité des cas, puis celle qui élimine le plus grand nombre de cas restants, et ainsi de suite. À la fin de chaque vérification, n’oubliez pas d’appeler la fonction de rappel, idéalement avec un return (JavaScript) pour quitter la fonction (Rule).

​
Réduire au minimum les requêtes aux API

Les appels aux API, en particulier aux API tierces, peuvent ralentir le temps de réponse à la connexion et provoquer des expirations de délai dans les Rules en raison de la latence des appels, ce qui peut au final entraîner des erreurs d’authentification. Nous recommandons de limiter autant que possible les requêtes aux API dans une Rule et d’éviter les appels excessifs à des services payants. Nous vous recommandons également de réduire les risques potentiels pour la sécurité en limitant les données envoyées à toute API, tierce ou non. L’objet global peut être utilisé pour mettre en cache les informations provenant d’appels aux API, qui pourront ensuite être réutilisées dans toutes les Rules exécutées dans le pipeline. Il est préférable de l’utiliser pour stocker ces informations plutôt que d’appeler une API de façon répétée. De plus, l’objet global peut aussi servir à mettre en cache d’autres informations entre l’exécution des Rules.

​
Limiter les appels aux services payants

Si vous avez des Rules qui font appel à des services payants, comme l’envoi de messages SMS au moyen de Twilio, assurez-vous de n’utiliser ces services que lorsque c’est nécessaire. Cela améliore non seulement les performances, mais aide aussi à éviter des frais supplémentaires. Pour réduire les appels aux services payants :
  • Désactivez les inscriptions publiques afin de réduire le nombre d’utilisateurs pouvant s’inscrire et déclencher des appels à des services payants
  • Assurez-vous qu’une Rule ne se déclenche que pour un sous-ensemble autorisé d’utilisateurs ou dans d’autres conditions appropriées. Par exemple, vous pouvez ajouter une logique qui vérifie si le courriel d’un utilisateur appartient à un domaine particulier, ou si l’utilisateur a un rôle/groupe ou un niveau d’abonnement précis, avant de déclencher l’appel au service payant.

​
Limitez les appels à la Management API

Essayez d’éviter autant que possible les appels à l’Auth0 Management API. L’Auth0 Management API est soumise à des limites de débit, ce qui reste à prendre en compte même lorsque vous utilisez l’objet auth0 (veillez donc à l’utiliser avec parcimonie). Pour en savoir plus, consultez les limites de débit des points de terminaison de la Management API. De plus, les fonctions de la Management API prennent plus ou moins de temps à s’exécuter et entraînent donc des niveaux de latence variables; par exemple, les appels au point de terminaison Lister ou rechercher des utilisateurs de la Management API doivent être réduits au minimum et effectués uniquement lorsque cela est absolument nécessaire, même lorsqu’ils sont exécutés au moyen de l’objet auth0. Nous avons élargi les propriétés liées aux connexions disponibles dans l’objet context des Rules, afin que vous puissiez obtenir les renseignements sur la connexion à partir de l’objet context sans avoir à appeler le Management API d’Auth0. Pour en savoir plus, consultez les propriétés de l’objet Context dans les Rules. Pour voir cela en pratique, si vous utilisez le modèle de Rule Check if user email domain matches configured domain, consultez la plus récente version sur GitHub ou accédez à Auth0 Dashboard > Auth Pipeline > Rules, puis sélectionnez Create. Remarque : les changements récents ne modifieront pas le fonctionnement, mais amélioreront les performances des Rules qui reposaient auparavant sur des appels au Management API. Supprimer les appels au Management API (ainsi que l’appel supplémentaire requis pour obtenir le Jeton d’accès approprié) rendra votre code de Rule plus performant et plus fiable.

​
Utilisez des délais d’attente explicites lors des appels d’API

Lorsque vous appelez des API ou accédez à des services externes, envisagez de définir un ou plusieurs délais d’attente explicites. La valeur précise du délai d’attente dépend généralement de votre cas d’utilisation, mais, de façon générale, il est recommandé d’en choisir une aussi courte que possible, tout en tenant compte des caractéristiques de performance du service externe. Que vous utilisiez des délais d’attente explicites ou un traitement implicite des délais d’attente, assurez-vous toujours de gérer les erreurs et/ou les exceptions qui peuvent survenir lorsqu’un délai expire. Pour en savoir plus, consultez les pratiques exemplaires de gestion des erreurs.

​
Réduire les appels à Auth0

Lorsque vous dépassez vos limites de taux, vous devez réduire le nombre d’appels effectués à Auth0. La marche à suivre dépend de votre cas d’utilisation, mais voici quelques recommandations :
  • Mettez en cache les réponses /.well-known/* : ces informations changent peu souvent; vous pouvez donc généralement les mettre en cache afin de réduire le nombre d’appels à Auth0.
  • Envisagez de demander un id_token au lieu d’appeler /userinfo pour obtenir des renseignements sur l’utilisateur.
  • Réduisez les appels groupés, comme la suppression ou le déverrouillage groupés.

​
Pour en savoir plus