Skip to main content
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).
permet de essayer avec TRY une règle à des fins de test et de débogage. Cette fonction permet de définir des objets user et context fictifs, qui sont ensuite transmis à la règle dans le cadre de son exécution. Le résultat de la règle (y compris la journalisation de la console) est affiché à la fin de l’exécution. Bien qu’il s’agisse d’un moyen immédiat de tester une règle à l’unité, il s’agit d’une approche très manuelle, qui ne permet pas de tirer parti d’outils de test automatisés tels que Mocha ou rewire. En tant que meilleure pratique, et dans le cadre de l’assistance recommandée pour le cycle de vie du développement logiciel, vous devriez utiliser un locataire de test séparé dans Auth0 pour tester toute nouvelle règle ou tout changement de règle avant de les déployer en production.

​
Automatisation

Avec l’aide d’un petit modèle, il est toutefois possible de mettre en œuvre une règle qui peut être déployée et exécutée dans un locataire Auth0 et, sans modification, être consommée dans n’importe quel environnement de test (unitaire) automatisé d’intégration continue/déploiement continu (CI/CD) : 
const vm = require('vm');
  const fs = require('fs');
  var user = {
      "name":        "jdoe@foobar.com",
      "email":       "jdoe@foobar.com",
      "user_id":     "auth0|0123456789",
          .
          .
    };
  var context = {
      "clientID":            "123456789",
      "clientName":          "MyWebApp",
      "connection":          "MyDbConn",
      "connectionStrategy":  "auth0",
      "protocol":            "oidc-basic-profile",
          .
          .
    };

  global.configuration = {
    DEBUG: true
  };

  vm.runInThisContext(
      "(()=>{return " + fs.readFileSync('./rules/Normalized Profile Claims.js') + " })();", {
        // filename for stack traces
        filename: 'Normalized Profile Claims.js',
        displayErrors: true
      }
  )(
    user,
    context,
    function callback() {
      console.log("Complete");
    }
  );
Comme le montre l’exemple ci-dessus, certains tests relativement simples peuvent être mis en œuvre (dans un module de nœud indépendant) en utilisant Node.js VM pour exécuter la règle à tester. Dans ce cas, une règle nommée Demandes de profil normalisées est lue à partir d’un fichier, et un modèle de code est ajouté autour du code de la règle (JavaScript) avant de l’exécuter (le modèle de code se trouve dans les chaînes qui préfixent et suffixent l’appel du système de fichiers à lire le fichier contenant le code de la règle). L’objet options transmis lors de l’appel à runInThisContext fournit des informations qui peuvent être utilisées pour faciliter le débogage dans le cas où une ou plusieurs conditions d’erreur exceptionnelles pourraient survenir. Veuillez consulter la documentation Node.js pour de plus amples informations concernant cet appel de fonction. Les deux premiers objets transmis à la règle pendant les tests représentent les objets user et context, qui peuvent être simulés d’une manière similaire à celle employée dans la fonctionnalité Auth0 Dashboard TRY. La fonction callback, fournie en tant que troisième paramètre, peut être mise en œuvre pour simuler la poursuite du pipeline, en exécutant ensuite la règle suivante dans l’ordre. La fonction callback fournie peut être utilisée pour s’assurer que l’exécution de la fonction de rappel est effectuée au moins une fois en demandant à la fonction (de rappel) de terminer le test et/ou de fournir une assertion. Nous recommandons également de prévoir une implémentation pour garantir que l’exécution multiple de la fonction callback n’est pas effectuée par une règle. En outre, l’objet (Node.js) global peut être utilisé pour fournir à la fois l’objet de configuration et une instance de l’objet auth0 si nécessaire. Dans l’exemple ci-dessus, un objet configuration global a été défini, ce qui est conforme aux pratiques recommandées pour faciliter le débogage (comme décrit dans la section ci-dessus). L’exemple précédent utilise également la structure de répertoire du système de fichiers fournie par l’outil Auth0 Deploy CLI, qui peut faciliter le déploiement des règles.
⌘I