Passer au contenu principal
Les scripts d’action s’exécutent comme une série de fonctions appelées JavaScript dans une instance d’un conteneur Webtask sans serveur. Dans ce cadre, un environnement particulier est fourni, ainsi qu’un certain nombre d’artefacts issus à la fois du conteneur Webtask et du serveur d’authentification Auth0 (votre locataire Auth0) lui-même.

​
modules npm

Les conteneurs Webtask sans serveur Auth0 peuvent utiliser une vaste gamme de modules npm; les modules npm ne réduisent pas seulement la taille globale de l’implémentation du code du script d’action, mais fournissent également un accès à une large gamme de fonctionnalités préconstruites. Par défaut, une grande liste de modules npm accessibles au public est prise en charge immédiatement. Cette liste a été compilée et vérifiée pour écarter tout problème de sécurité potentiel. Pour savoir quels modules npm sont pris en charge, consultez Puis-je exiger : extensibilité Auth0. Si vous avez besoin d’un module npm qui n’est pas pris en charge par défaut, vous pouvez en faire la demande à partir du Portail d’extensibilité Auth0) ou par l’intermédiaire de votre représentant Auth0. Auth0 évaluera votre demande pour en déterminer la pertinence. Si vous devez escalader une demande non résolue, ouvrez un ticket d’assistance à partir du Portail d’assistance Auth0. Il n’y a actuellement aucune prise en charge dans Auth0 pour l’utilisation de modules npm à partir de référentiels privés.

​
Variables

Les scripts d’action d’Auth0 prennent en charge la notion de variables d’environnement. On peut y accéder à partir de l’objet de configuration accessible partout dans le monde. L’objet de configuration devrait être en lecture seule, et devrait servir au stockage d’informations sensibles, telles que des identifiants ou des clés API permettant d’accéder à des magasins d’identité externes. Cela atténue le risque d’avoir des valeurs sensibles à la sécurité codées en dur dans un script d’action. L’objet de configurationpeut aussi servir à soutenir les stratégies de meilleures pratiques du cycle de vie du développement logiciel que vous utilisez, comme la confirguration d’environnements multiples, en vous permettant de définir des variables ayant des valeurs propres à chaque locataire. Cela atténue les valeurs codées en dur dans un script d’action, qui peuvent changer en fonction du locataire qui l’exécute.

​
objet global

Les conteneurs Webtask sans serveur Auth0 sont fournis à partir d’une banque associée à chaque locataire Auth0. Chaque instance de conteneur met à disposition un objet global, auquel il est possible d’accéder à partir de tous les scripts d’action qui s’exécutent en son sein (l’instance de conteneur). L’objet global agit comme une variable globale unique au conteneur, qui peut être utilisée pour définir des informations ou même des fonctions susceptibles d’être utilisées dans tous les scripts d’action qui s’exécutent dans l’instance de conteneur. Cela signifie que l’objet global peut être utilisé pour mettre en cache des ressources coûteuses tant que ces ressources ne sont pas propres à l’utilisateur. Par exemple, on pourrait stocker un jeton d’accès pour une API tierce (p. ex., de connexion) qui fournit des fonctionnalités non propres à l’utilisateur. Il pourrait également être utilisé pour stocker un jeton d’accès à votre propre API non liée à l’utilisateur, défini dans Auth0 et obtenu par l’utilisation du flux des identifiants client.
Un script d’action peut s’exécuter dans n’importe quelle instance de conteneur déjà en cours d’exécution ou dans une instance de conteneur nouvellement créée (qui peut être ajoutée ultérieurement au pool). Aucune affinité de conteneur n’existe pour l’exécution de scripts d’action dans Auth0. Cela signifie que vous devez éviter de stocker des informations spécifiques à l’utilisateur dans l’objet global et devez toujours vous assurer que toute déclaration faite dans l’objet global prévoit également l’initialisation.
Chaque fois qu’un conteneur de tâches Web est recyclé, ou pour chaque instanciation d’un nouveau conteneur de tâches Web, l’objet global qu’il définit est réinitialisé. Ainsi, toute déclaration d’affectation dans l’objet global associé à un conteneur doit également prévoir l’initialisation. Pour fournir une flexibilité au niveau de la performance, les conteneurs Webtask sans serveur sont provisionnés dans Auth0 sur une base ad hoc et sont également soumis à diverses politiques de recyclage. En général, nous vous recommandons de ne pas considérer la durée de vie d’un objet global comme étant supérieure à 20 minutes.

​
Liste de contrôle de l’environnement de connexion à la base de données personnalisée

  • Assurez-vous que votre base de données possède les champs appropriés pour stocker les attributs des profils utilisateurs, tels que id, nickname, email, et password. Pour en savoir plus sur le schéma de profil utilisateur d’Auth0 et les champs attendus, consultez Profils utilisateurs normalisés. Pour apprendre à mettre à jour des profils utilisateurs, consultez Mise à jour des profils utilisateurs à l’aide de votre base de données.
  • Vous pouvez retourner les erreurs résultant de votre connexion à la base de données personnalisée à des fins de dépannage.
  • La propriété id (ou user_id) dans le profil utilisateur retourné sera utilisée par Auth0 pour identifier l’utilisateur. Si vous utilisez plusieurs connexions par bases de données personnalisées, la valeur id doit être unique dans toutes les connexions par bases de données personnalisése pour éviter les collisions d’ID d’utilisateurs. Notre recommandation est d’ajouter le nom de la connexion (sans espace) en préfixe à la valeur de id. Pour en savoir plus à propos des ID utilisateurs, lisez Identifier les utilisateurs.
  • La latence sera plus élevée par rapport aux magasins d’utilisateurs hébergés par Auth0.
  • La base de données ou le service doit être accessible depuis les serveurs Auth0. Vous allez devoir configurer les connexions entrantes si votre magasin se trouve derrière un pare-feu.

​
Tester une version exécutable particulière.

La version exécutable pour les scripts de base de données personnalisés est définie dans Dashboard (Tableau de bord) > Settings (Paramètres) > Advanced (Avancés) dans la section Extensibility (Extensibilité). Suivez ces étapes pour tester un script de base de données personnalisé unique sur une version exécutable particulière :
  1. Naviguez vers Authentication (Authentification) > Database (Base de données).
  2. Sélectionnez la connexion à la base de données où vous avez défini un script personnalisé.
  3. Dans la page de la connexion à la base de données sélectionnée, choisissez l’onglet Custom Database (Base de données personnalisée) .
  4. Faites défiler jusqu’à la section Database Action Scripts (Scripts d’action de la base de données) de la page.
  5. Sélectionnez le script particulier que vous souhaitez vérifier (p. ex., Connexion, Création, etc.) dans l’onglet correspondant.
  6. Sélectionnez Save and Try (Enregistrer et Essayer). Cela permet de charger une fenêtre modale contenant les paramètres particuliers du test et les détails du contexte de l’échantillon. Mettre à jour au besoin.
  7. Sélectionnez Try (Essayer) dans la fenêtre modale pour ouvrir un sélecteur déroulant pour une version particulière de Node.
  8. Le test démarre une fois que la version de Node désirée est choisie, et les résultats sont affichés dans un message sur le même écran.

​
En savoir plus

⌘I