Pratiques exemplaires pour la gestion des erreurs

Découvrez les pratiques exemplaires en matière de gestion des erreurs.

Envoyer les journaux d’erreurs à un service externe

Nous vous recommandons d’envoyer les journaux des événements d’erreur à un service externe afin d’améliorer la visibilité et de faciliter le diagnostic des comportements anormaux. Pour conserver et analyser vos événements de journal au-delà de la période de conservation offerte par votre forfait, utilisez la diffusion des journaux Auth0. Vous pouvez utiliser des services comme DataDog et AWS EventBridge. Nous offrons également la possibilité d’envoyer des journaux à un service externe dans la section Log Streaming d’Auth0 Marketplace.

Utiliser des objets d’erreur dans les Rules

L’exécution d’une Rule est soumise à des contraintes de temps. Pour en savoir plus, consultez Custom Database Action Script Execution Best Practices. S’il n’est pas possible (ou probable) de récupérer d’une erreur dans ce délai, la condition d’erreur doit alors être renvoyée explicitement; pour ce faire, il suffit de terminer l’exécution de la Rule en renvoyant une instance de l’objet Node Error, comme dans l’exemple suivant :

return callback(new Error('some description'));

Pour en savoir plus, consultez Class: Error on nodejs.org.

Autrement, vous pouvez renvoyer une instance de UnauthorizedError propre à Auth0, ce qui entraîne le renvoi d’une erreur unauthorized accompagnée de la description fournie à l’application qui a lancé l’authentification, c’est-à-dire l’application à partir de laquelle la redirection vers le point de terminaison /authorize a été lancée. Cela permet à une application d’offrir une possibilité de nouvelle tentative conditionnelle et vous permet d’implémenter des Rules pour refuser l’accès selon certaines conditions :

return callback(new UnauthorizedError('some description'), user, context);

Utilisez des descriptions de code d’erreur explicites

L’objet UnauthorizedError renvoie uniquement la description fournie. Pour traiter spécifiquement les erreurs d’autorisation, nous vous recommandons de formater vos descriptions de manière à y inclure un code d’erreur facilement repérable, par exemple :

'[00043] - my specific error description')

Gestion des exceptions

Des erreurs inattendues, comme des exceptions JavaScript non interceptées, peuvent interrompre prématurément l’exécution du pipeline, ce qui finit par renvoyer une erreur d’authentification.

Dans les cas impliquant des opérations asynchrones, vous devez utiliser un gestionnaire catch lorsque vous traitez des objets Promise. Le traitement des objets Promise peut aussi être utile pour gérer les erreurs lors d’opérations non asynchrones. Comme illustré ci-dessous, un objet Promise peut servir à encapsuler, par exemple, l’appel d’une fonction synchrone, ce qui facilite la mise en place d’une gestion des erreurs en cascade au moyen de l’enchaînement de promesses et de techniques similaires. Pour en savoir plus sur l’objet Promise, consultez Promise dans MDN Web Docs. Pour en savoir plus sur l’enchaînement de promesses, consultez Error Handling with Promises 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);
      }
    });
  });

Sinon, vous pouvez utiliser un bloc try...catch pour gérer les exceptions JavaScript qui surviennent pendant une opération synchrone. Pour en savoir plus, consultez try...catch dans MDN Web Docs.La mise en place de ce type de gestion des exceptions peut souvent avoir un coût en matière de performances, alors utilisez-le avec parcimonie; les performances des Rules doivent être aussi optimales que possible. Une approche plus pragmatique consiste à concevoir le traitement de manière à éviter les exceptions plutôt qu’à les gérer une fois qu’elles se produisent. Pour en savoir plus sur les pratiques exemplaires, consultez Pratiques exemplaires en matière de performance.

Évitez les objets non initialisés dans les Rules

Si vous utilisez des objets non initialisés, cela peut provoquer des exceptions. Nous vous recommandons d’inclure l’initialisation dans toute déclaration lorsque l’existence d’un objet est incertaine. Par exemple :

user.user_metadata = user.user_metadata || {})

Dans une Rule, prendre les mesures nécessaires pour éviter qu’une exception se produise dès le départ constitue une bonne pratique et coûte généralement moins cher en performance et en ressources que d’implémenter une gestion des exceptions.