Passer au contenu principal
La date de fin de vie (EOL) de Rules et Hooks est fixée au 18 novembre 2026, et ils ne sont plus offerts aux nouveaux locataires créés à compter du 16 octobre 2023. Les locataires existants qui ont des Hooks actifs conserveront l’accès au produit Hooks jusqu’à la fin de vie.Nous vous recommandons fortement d’utiliser Actions pour étendre Auth0. Avec Actions, vous avez accès à des informations de type enrichies, à de la documentation intégrée et à des packages npm publics, et vous pouvez connecter des intégrations externes qui améliorent votre expérience globale d’extensibilité. Pour en savoir plus sur ce qu’offre Actions, consultez Understand How Auth0 Actions Work.Pour vous aider dans votre migration, nous proposons des guides pour migrate from Rules to Actions et migrate from Hooks to Actions. Nous avons aussi une page dédiée, Move to Actions, qui présente des comparaisons de fonctionnalités, une démo d’Actions et d’autres ressources pour vous accompagner dans votre migration.Pour en savoir plus sur la dépréciation de Rules et Hooks, consultez notre billet de blogue : Preparing for Rules and Hooks End of Life.
La page de connexion Auth0 ne peut pas afficher un message d’erreur provenant d’une Rule. Si vous voulez que les utilisateurs voient un message personnalisé généré par une Rule, votre application doit l’afficher. Toute erreur provenant d’une Rule est envoyée à votre URL de rappel selon le mode de réponse standard du protocole. Par exemple, si votre application demande une authentification au moyen d’OIDC/OAuth2, elle reçoit une erreur OAuth2 standard avec les valeurs de résultat error et error_description. Supposons que votre URL de rappel soit https://travel0.com/callback et que vous utilisez le mode de réponse par requête standard. Vous recevriez cette réponse : 
https://travel0.com/callback?error=access_denied&error_description=[The message you wrote in the rule]
Votre application doit afficher le message à l’utilisateur, par exemple :
Exemple de message d’erreur indiquant

​
Réessayer de se connecter après une erreur de Rule

L’étape suivante consiste souvent à demander une nouvelle autorisation. Toutefois, dans la plupart des cas, Auth0 sait déjà qui est l’utilisateur et ne lui redemande donc pas ses renseignements de connexion. Les Rules s’exécutent alors immédiatement, et la Rule refuse de nouveau l’autorisation. Cela peut créer une boucle sans fin. L’utilisateur doit pouvoir fournir de nouveaux identifiants. Votre application peut réafficher la page de connexion de deux façons :
  • Ajoutez une directive à la requête pour forcer l’affichage de la page de connexion :
    • Utilisez un paramètre prompt=login dans une requête OIDC/OAuth2.
    • Utilisez un attribut ForceAuthn="true" dans une requête SAML.
—ou—
  • Déconnectez l’utilisateur d’Auth0 avant d’envoyer une nouvelle requête.

​
En savoir plus