Générer des erreurs à partir des règles
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).
La page de connexion Auth0 ne peut pas afficher un message d’erreur provenant d’une règle. Si vous souhaitez que les utilisateurs voient un message personnalisé généré par une règle, votre application doit afficher le message en question.
Toute erreur résultant d’une règle est transmise à votre URL de rappel dans le mode de réponse standard du protocole. Par exemple, si votre application demande une authentification à l’aide de OIDC/OAuth2, elle reçoit une erreur OAuth2 standard avec les valeurs obtenues error et error_description.
Toute erreur résultant d’une règle est transmise à votre URL de rappel dans le mode de réponse standard du protocole. Par exemple, si votre application demande une authentification à l’aide de OIDC/OAuth2, elle reçoit une erreur OAuth2 standard avec les valeurs obtenues error et error_description.
https://travel0.com/callback?error=access_denied&error_description=[The message you wrote in the rule]Was this helpful?
C’est le rôle de votre application d’afficher le message à l’utilisateur, tel que :
Retenter la connexion après une erreur de règle
L’étape suivante consistera probablement à demander une nouvelle autorisation. Cependant, dans la plupart des cas, Auth0 connaît déjà l’identité de l’utilisateur et ne requiert donc pas les informations de connexion. Au lieu de cela, les règles s’exécutent immédiatement et la règle refuse à nouveau l’autorisation. Ce processus peut devenir une boucle sans fin.
L’utilisateur doit avoir la possibilité de fournir de nouveaux identifiants. Vous pouvez réafficher la page de connexion de deux manières différentes :
Ajouter une directive dans la requête pour forcer l’affichage de la page de connexion :
Utiliser un paramètre
prompt=logindans une requête OIDC/OAuth2.Utiliser un attribut
ForceAuthn="true"dans une requête SAML.
—ou—
Déconnecter l’utilisateur d’Auth0 avant d’envoyer une nouvelle demande.