Passer au contenu principal
Les scripts d’Action s’exécutent comme une série de fonctions JavaScript appelées dans une instance de conteneur Webtask sans serveur. Dans ce contexte, un environnement précis est fourni, ainsi qu’un certain nombre d’éléments fournis à la fois par le conteneur Webtask et par le Auth0 lui-même (votre locataire Auth0).

​
Modules npm

Les conteneurs Webtask sans serveur d’Auth0 peuvent utiliser un large éventail de modules npm ; les modules npm réduisent non seulement la taille globale du code d’implémentation du script Action, mais donnent aussi accès à un vaste ensemble de fonctionnalités prêtes à l’emploi. Par défaut, une longue liste de modules npm accessibles publiquement est prise en charge d’emblée. Cette liste a été compilée et validée afin d’écarter tout risque de sécurité potentiel. Pour voir quels modules npm sont pris en charge, consultez Can I require: Auth0 Extensibility. Si vous avez besoin d’un module npm qui n’est pas pris en charge d’emblée, vous pouvez en faire la demande dans le portail Auth0 Extensibility ou auprès de votre représentant Auth0. Auth0 évaluera votre demande pour en déterminer la pertinence. Si vous devez faire remonter une demande non résolue, ouvrez un ticket d’assistance dans le portail d’assistance Auth0. À l’heure actuelle, Auth0 ne prend pas en charge l’utilisation de modules npm provenant de dépôts privés.

​
Variables

Les scripts d’Action d’Auth0 prennent en charge les variables d’environnement, accessibles au moyen de l’objet configuration, défini comme étant disponible globalement. L’objet configuration doit être traité comme étant en lecture seule et doit servir à stocker des données sensibles, comme des informations d’identification ou des clés API permettant d’accéder à des répertoires d’identités externes. Cela évite d’inclure en dur des valeurs sensibles pour la sécurité dans un script d’Action. L’objet configuration peut également servir à prendre en charge les stratégies de bonnes pratiques du cycle de vie du développement logiciel (SDLC) que vous utilisez, comme la configuration de plusieurs environnements, en vous permettant de définir des variables dont les valeurs sont propres au locataire. Cela évite d’avoir des valeurs codées en dur dans un script d’Action, lesquelles peuvent changer selon le locataire qui l’exécute.

​
objet global

Les conteneurs Webtask sans serveur d’Auth0 sont provisionnés à partir d’un pool associé à chaque locataire Auth0. Chaque instance de conteneur met à disposition un objet global, auquel tous les scripts d’Action exécutés à l’intérieur de celui-ci (l’instance de conteneur) peuvent accéder. L’objet global agit comme une variable globale propre au conteneur et peut être utilisé pour définir des informations — ou même des fonctions — qui peuvent servir dans tous les scripts d’Action exécutés à l’intérieur de celui-ci (l’instance de conteneur). Cela signifie que l’objet global peut servir à mettre en cache des ressources coûteuses, tant que ces ressources ne sont pas propres à un utilisateur. Par exemple, un pour une API tierce (par ex. de journalisation) qui fournit des fonctionnalités non propres à l’utilisateur pourrait y être stocké. Il pourrait aussi servir à stocker un Jeton d’accès pour votre propre API non propre à l’utilisateur définie dans Auth0 et obtenu au moyen du flux Client Credentials.
Un script d’Action peut s’exécuter dans n’importe laquelle des instances de conteneur déjà en cours d’exécution ou dans une nouvelle instance de conteneur (qui pourra ensuite être ajoutée au pool). Il n’existe aucune affinité de conteneur pour l’exécution des scripts d’Action dans Auth0. Cela signifie que vous devez éviter de stocker toute information propre à l’utilisateur dans l’objet global et toujours vous assurer que toute déclaration faite dans l’objet global prévoit également l’initialisation.
Chaque fois qu’un conteneur Webtask est recyclé, ou à chaque instanciation d’un nouveau conteneur Webtask, l’objet global qu’il définit est réinitialisé. Ainsi, toute déclaration d’affectation dans l’objet global associé à un conteneur doit aussi prévoir l’initialisation. Pour offrir une flexibilité sur le plan des performances, les conteneurs Webtask sans serveur sont provisionnés dans Auth0 de façon ponctuelle et sont aussi assujettis à diverses politiques de recyclage. En général, nous recommandons de ne pas considérer que la durée de vie d’un objet global dépasse 20 minutes.

​
Liste de vérification de l’environnement d’une connexion à une base de données personnalisée

  • Assurez-vous que votre base de données contient les champs appropriés pour stocker les attributs du profil utilisateur, comme id, nickname, email et password. Pour en savoir plus sur le schéma de profil utilisateur d’Auth0 et les champs attendus, consultez Normalized User Profiles. Pour savoir comment mettre à jour les profils utilisateurs, consultez Update User Profiles Using Your Database.
  • Vous pouvez utiliser, à des fins de dépannage, les erreurs renvoyées par votre connexion à une base de données personnalisée.
  • La propriété id (ou user_id) du profil utilisateur renvoyé sera utilisée par Auth0 pour identifier l’utilisateur. Si vous utilisez plusieurs connexions à des bases de données personnalisées, la valeur de id doit être unique dans l’ensemble de ces connexions afin d’éviter les collisions d’ID utilisateur. Nous vous recommandons de préfixer la valeur de id avec le nom de la connexion (sans espaces). Pour en savoir plus sur les ID utilisateur, consultez Identify Users.
  • La latence sera plus élevée que pour les répertoires d’utilisateurs hébergés par Auth0.
  • La base de données ou le service doit être accessible depuis les serveurs d’Auth0. Vous devrez configurer les connexions entrantes si votre répertoire se trouve derrière un pare-feu.

​
Tester une version de runtime précise

La version de runtime des scripts de base de données personnalisés est définie dans Dashboard > Settings > Advanced, dans la section Extensibility. Suivez ces étapes pour tester un script de base de données personnalisé avec une version de runtime précise :
  1. Accédez à Authentication > Database.
  2. Sélectionnez la connexion de base de données dans laquelle vous avez défini un script personnalisé.
  3. Dans la page de la connexion de base de données sélectionnée, choisissez l’onglet Custom Database.
  4. Faites défiler la page jusqu’à la section Database Action Scripts.
  5. Sélectionnez le script précis que vous voulez vérifier (p. ex. Login, Create, etc.) dans l’onglet correspondant.
  6. Sélectionnez Save and Try. Une fenêtre modale s’ouvre avec des paramètres de test précis et des détails de contexte d’exemple. Mettez-les à jour au besoin.
  7. Sélectionnez Try dans la fenêtre modale pour ouvrir une liste déroulante permettant de choisir une version précise de Node.
  8. Le test se lance lorsque vous sélectionnez la version de Node voulue, et les résultats s’affichent dans un message sur le même écran.

​
En savoir plus