Skip to main content
La date de fin de vie (EOL) des Règles et des Appels sera le 18 novembre 2026. Ils ne sont plus disponibles pour les nouveaux locataires créés à partir du 16 octobre 2023. Les locataires actuels ayant des hooks actifs conserveront l’accès aux produit Hooks jusqu’à la fin de leur durée de vie.Nous vous conseillons vivement d’utiliser les Actions pour étendre Auth0. Avec les Actions, vous avez accès à des informations de type enrichies, à une documentation intégrée et à des packages npm publics, et vous pouvez connecter des intégrations externes qui optimisent votre expérience d’extensibilité globale. Pour en savoir plus sur ce que les Actions proposent, consultez Comprendre comment fonctionnent Auth0 Actions.Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à migrer des Règles vers les Actions et à migrer des Hooks vers les Actions. Nous avons également une page dédiée à la Migration vers les Actions qui met en évidence les comparaisons de fonctionnalités, une démo des Actions et d’autres ressources pour vous aider dans votre parcours de migration.Pour en savoir plus sur l’obsolescence des Règles et des Appels, consultez notre article de blog : Preparing for Rules and Hooks End of Life (Préparation à la fin de vie des règles et des crochets).
Une règle est essentiellement une fonction JavaScript anonyme à laquelle sont transmis trois paramètres : un objet user, un objet context et une fonction de callback. 
function (user, context, callback) {
     // TODO: implement your rule
     return callback(null, user, context);
    }
N’ajoutez pas de point-virgule à la fin de la déclaration de la fonction, car cela interromprait l’exécution de la règle. Les fonctions anonymes compliquent l’interprétation de la pile d’appels générée à la suite d’une condition d’erreur exceptionnelle. Pour faciliter l’analyse diagnostique, utilisez des conventions de dénomination compactes et uniques (p. ex., function MyRule1 (user, context, callback) {...}). Pour en savoir plus, consultez Meilleures pratiques en matière de traitement des erreurs. Les règles s’exécutent dans le pipeline associé à la génération d’artefacts pour l’authenticité qui fait partie du moteur global Auth0. Toutes les règles activées sont regroupées dans l’ordre dans lequel elles sont énumérées et envoyées sous la forme d’un blob de code à exécuter en tant que tâche Web sans serveur Auth0 lorsqu’un pipeline est exécuté. Pour voir l’ensemble du moteur Auth0, téléchargez Fonctionnement du moteur Auth0..
Diagramme du pipeline de règles des meilleures pratiques d'anatomie des règles

​
Poids

Nous recommandons que la taille totale de la mise en œuvre de toutes les règles activées ne dépasse pas 100 ko. Plus la taille est importante, plus cela introduit de la latence en raison du processus de conditionnement et de transport utilisé par la plateforme Webtask sans serveur Auth0, ce qui aura des répercussions sur les performances de votre système. Notez que la limite de 100 ko n’inclut pas les modules npm qui peuvent être référencés dans le cadre de déclarations require.

​
Ordre

L’ordre dans lequel les règles sont affichées dans dicte l’ordre dans lequel les règles seront exécutées. Cela est important,car une règle peut donner une ou plusieurs définitions dans l’environnement associé à l’exécution dont une autre règle peut dépendre. En pareil cas, la règle qui établit la ou les définitions doit s’exécuter avant la règle qui l’utilise. Pour en savoir plus, consultez Meilleures pratiques en matière d’environnement des règles. Exécutez les règles coûteuses qui font appel aux API (y compris Management API d’Auth0) le plus tard possible. Si d’autres règles, moins coûteuses, sont susceptibles d’entraîner la détermination d’un accès unauthorized, il convient de les exécuter en premier lieu.

​
En savoir plus