Meilleures pratiques de test des règles
Auth0 Dashboard 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");
}
);
Was this helpful?
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.