La propriété consoleOut est une sortie de journal générée par les clients sur la plateforme Auth0 au moyen d’Actions, de Rules, de Hooks, d’Extensions et de DB Scripts. Auth0 recommande d’utiliser la propriété consoleOut uniquement à des fins de test et de débogage. Vous ne devriez pas consigner de données personnelles ni d’autres données sensibles dans la console Web, faute de quoi la sortie du journal contiendra ces données.
En règle générale, vous déboguez une règle au moment de l’exécution à l’aide de la journalisation dans la console avec la fonction console.log. Pour en savoir plus, consultez console.log() dans MDN Web Docs. Aucun débogage interactif d’une règle n’est offert sur la plateforme Auth0 (bien qu’il soit possible d’utiliser la technique d’automatisation des tests décrite ci-dessous avec un outil externe interactif de débogage du code source).
Ajouter suffisamment de commentaires de ligne (c.-à-d. //) ou de bloc (c.-à-d. /* */) à une règle, en particulier autour des fonctionnalités moins évidentes, est extrêmement utile, tant pour le débogage que pour la compréhension du code, surtout qu’il arrive souvent que la personne qui implémente initialement une règle ne soit pas celle qui en assurera la maintenance par la suite.
Par défaut, la sortie de la console n’est pas affichée pendant l’exécution normale. Toutefois, vous pouvez utiliser les journaux en temps réel des Actions pour afficher en temps réel tous les journaux de la console pour l’extensibilité implémentée dans un locataire Auth0. L’affichage en temps réel des journaux de la console comprend la sortie de console.log, de console.error et de console.exception.
Activer et désactiver la journalisation de débogage
Dans un environnement de production, la journalisation de débogage n’est pas souhaitable en permanence; compte tenu des considérations de performance associées aux Rules, il ne serait pas prudent de la laisser activée en continu. Pour en savoir plus, consultez Bonnes pratiques en matière de performance.Dans un environnement de développement ou de test, en revanche, il peut être utile de l’activer plus régulièrement. De plus, une journalisation de débogage excessive peut générer beaucoup de « bruit », ce qui complique davantage l’identification des problèmes.Modifier une règle pour activer ou désactiver la journalisation de débogage selon l’environnement serait lourd et source d’erreurs. Il vaut mieux exploiter l’objet de configuration de l’environnement pour mettre en place un traitement conditionnel, comme dans l’exemple suivant :
function NPClaims(user, context, callback) { /* * Cette règle (https://auth0.com/docs/rules) est utilisée pour dériver * les revendications effectives associées au profil utilisateur normalisé : * https://auth0.com/docs/user-profile/normalized/auth0 */ var LOG_TAG = '[NORMALIZED_PROFILE_CLAIMS]: '; var DEBUG = configuration.DEBUG ? console.log : function () {}; DEBUG(LOG_TAG, "identities=", user.identities); user.user_metadata = user.user_metadata || {}; // user.family_name = user.family_name || user.identities.filter(function(identity) { /* Exclure les identités qui ne contiennent rien d'équivalent au * nom de famille */ return( identity.profileData && identity.profileData.family_name); }).map(function(identity) { return identity.profileData.family_name; })[0]; DEBUG(LOG_TAG, "Computed user.family_name as '", user.family_name, "'"); . . // return callback(null, user, context); }
Dans l’exemple ci-dessus, une variable de configuration d’environnement DEBUG a été créée. Elle peut être définie à true ou à false selon l’environnement d’exécution (p. ex., production, test, développement). Le réglage de cette variable sert à déterminer à quel moment la journalisation de débogage est effectuée. De plus, il serait possible, par exemple, de créer une variable de configuration d’environnement DEBUGLEVEL pour contrôler le niveau de journalisation du débogage (p. ex., détaillé, moyen, minimal).L’exemple ci-dessus montre également la déclaration d’une fonction nommée. Par souci de commodité, donner un nom à une fonction — au moyen d’une convention de nommage compacte et unique — peut faciliter l’analyse diagnostique. Les fonctions anonymes compliquent, en situation de débogage, l’interprétation de la pile d’appels générée à la suite d’une erreur exceptionnelle; l’attribution d’un nom de fonction unique permet d’y remédier. Pour en savoir plus, consultez Pratiques exemplaires de gestion des erreurs.
L’éditeur de règles de l’ offre une vérification syntaxique rudimentaire ainsi qu’une analyse de la sémantique des règles. Toutefois, il ne propose pas d’analyse statique du code plus avancée, comme la détection d’écrasement, la détection de boucles ou la détection de vulnérabilités. Pour pallier cette limite, envisagez d’utiliser des outils tiers — comme JSHint, SonarJS ou Coverity — en complément des tests de règles dans le cadre de votre processus d’automatisation du déploiement. Pour en savoir plus, consultez Deployment Best Practices.