Passer au contenu principal
Les conditions d’erreur renvoyées par les appels d’API doivent être gérées et traitées de manière appropriée. Le non-respect de cette consigne peut entraîner des exceptions non gérées, provoquant l’interruption prématurée de l’exécution du pipeline et, par conséquent, une erreur d’authentification.

​
Envoyer les journaux d’erreurs à un service externe

Nous vous recommandons d’envoyer les journaux d’erreurs à un service externe afin d’améliorer la visibilité et de faciliter le diagnostic en cas de dysfonctionnement. Pour conserver et analyser vos événements de journal au-delà de la période de conservation des journaux proposée pour votre plan d’abonnement, utiliser le streaming de journaux Auth0. Vous pouvez utiliser des services tels que DataDog et AWS EventBridge. Nous offrons également la possibilité d’envoyer des journaux à un service externe dans notre section Streaming des journaux dans Auth0 Marketplace.

​
Utiliser des objets d’erreur dans les règles

Il existe des contraintes temporelles qui limitent la durée d’exécution d’une règle. Pour en apprendre davantage, veuillez consulter Bonnes pratiques d’exécution de scripts d’action de base de données personnalisés. Si une condition d’erreur ne peut pas (ou probablement ne pourra pas) être résolue dans ce délai, il est nécessaire de renvoyer explicitement une erreur. Cela peut se faire simplement en terminant l’exécution de la règle en renvoyant une instance d’un objet Nœud de type Error, comme dans : return callback(new Error('some description')); Pour en savoir plus, veuillez consulter Classe : Ereurs sous nodejs.org. Alternativement, une instance spécifique à Auth0 UnauthorizedError peut être retournée. Cela déclenchera une condition d’erreur unauthorized avec la description de l’erreur fournie, laquelle sera renvoyée à l’application ayant initié l’authentification, c’est-à-dire celle à l’origine de la redirection vers le point de terminaison /authorize Cela permet à une application d’offrir une capacité de nouvelle tentative conditionnelle et vous permet d’implémenter des règles pour refuser l’accès en fonction de certaines conditions : return callback(new UnauthorizedError('some description'), user, context);

​
Utilisez des descriptions de codes d’erreur significatives

L’objet UnauthorizedError renvoie uniquement la description fournie. Pour utiliser un traitement spécifique pour les conditions d’erreur non autorisées, nous vous recommandons de formater vos descriptions pour inclure des informations de code d’erreur facilement accessibles, par exemple : '[00043] - ma description spécifique d’erreur')

​
Gestion des exceptions

Les conditions d’erreur inattendues, telles que les exceptions JavaScript non détectées peuvent entraîner l’arrêt prématuré de l’exécution du pipeline, ce qui entraînera finalement le renvoi d’une erreur d’authentification. Pour les situations impliquant des opérations asynchrones, vous devez utiliser un gestionnaire catch lors de l’utilisation du traitement d’objets Promise. Le traitement d’objets Promise peut également être efficace pour la gestion des erreurs lors d’opérations non-asynchrones. Comme illustré ci-dessous, un objet Promise peut être utilisé pour encapsuler, par exemple, un appel de fonction synchrone, ce qui facilite la mise en œuvre de la gestion des erreurs en cascade via l’utilisation du chaînage de Promise et autres. Pour en savoir plus sur l’objet Promise, veuillez consulter Promise dans MDN Web Docs. Pour en savoir plus sur le chaînage de Promise, veuillez consulter Gestion des erreurs avec Promise sur javascript.info. 
return new Promise(function(resolve, reject) {
    jwt.verify(
      token,
      secret,{
      clockTolerance: 5},
      function(err, decoded) {
        if (err) {
          reject(err);
        } else {
          resolve(decoded);
      }
    });
  });
Alternativement, vous pouvez utiliser le traitement try...catch (essayer...attraper) pour gérer les exceptions JavaScript qui se produisent pendant le fonctionnement synchrone. Pour en savoir plus, veuillez consulter try...catch dans MDN Web Docs.La configuration de ce type de gestion des exceptions peut engendrer des coûts en termes de performances. Il est donc recommandé de l’utiliser avec modération afin de maintenir des performances optimales pour vos règles. Une approche plus pragmatique consiste à mettre en œuvre un traitement qui empêche les exceptions de se produire plutôt que de les gérer une fois qu’elles se sont produites. Pour en savoir plus sur les meilleures pratiques, veuillez consulter Les meilleures pratiques en matière de performance.

​
Éviter les objets non initialisés dans les règles

Si vous utilisez des objets non initialisés, cela peut provoquer des exceptions. Nous vous recommandons d’inclure l’initialisation dans toute déclaration où l’existence d’un objet est en question. Par exemple : user.user_metadata = user.user_metadata || {}) Dans une règle, prendre des mesures pour empêcher qu’une exception ne se produise est une bonne pratique et est généralement moins coûteuse en termes de performances et d’utilisation des ressources que la mise en œuvre de la gestion des exceptions.

​
En savoir plus