Scripts d’action de base de données

Configurez et personnalisez la façon dont Auth0 interagit avec votre répertoire d’utilisateurs externe en écrivant des scripts d’action de base de données.

​

Utilisation

Les scripts d’action de base de données sont des fonctions Node.js que vous créez pour les connexions à une base de données personnalisée. Ils définissent la façon dont Auth0 interagit avec votre répertoire d’utilisateurs externe lors d’opérations telles que la connexion, le changement de mot de passe et la suppression d’utilisateurs.

Les scripts d’action de base de données s’exécutent sous la forme d’une série de fonctions JavaScript appelées dans une instance de conteneur Webtask serverless.

​

Achèvement et fonction callback

La signature de chaque script d’action de base de données inclut une fonction callback comme dernier paramètre. Auth0 fournit cette fonction callback, qui signale la fin de l’opération.

Chaque script d’action de base de données doit appeler sa fonction callback exactement une fois, immédiatement avant de se terminer (implicitement ou explicitement au moyen d’une instruction return). Le fait de ne pas exécuter la fonction callback bloque l’exécution et finit par retourner une erreur.

Pour le dépannage, vous pouvez retourner des erreurs à partir de vos scripts d’action de base de données en transmettant un objet Error à la fonction callback :

return callback(new Error('My custom error message'));

Appeler la fonction callback sans paramètre, comme dans callback(), revient à l’appeler avec callback(null).

​

JavaScript asynchrone

Les scripts d’action de base de données prennent en charge les fonctionnalités asynchrones de JavaScript, notamment les objets Promise et les fonctions async. Vous pouvez utiliser ces fonctionnalités pour exécuter des opérations non bloquantes à partir d’un script d’action.

Si votre script d’action utilise un traitement asynchrone, vous devez reporter l’appel de la fonction callback jusqu’à la fin du traitement. Les opérations asynchrones doivent se terminer dans la limite d’exécution du conteneur Webtask.

​

Modules npm publics

Les modules npm réduisent la taille globale des scripts d’action et donnent accès à un vaste éventail de fonctionnalités prédéfinies.

Les conteneurs Webtask serverless d’Auth0 peuvent utiliser de nombreux modules npm publics pris en charge. Si vous avez besoin d’un autre module, communiquez avec votre représentant Auth0 ou ouvrez un ticket de soutien.

Les scripts d’action ne prennent pas en charge les modules npm provenant de dépôts privés.

​

Éléments fournis

Nous fournissons un environnement spécifique comprenant un certain nombre d’éléments fournis à la fois par le conteneur Webtask et par le serveur d’authentification Auth0 (votre tenant Auth0) lui-même.

​

Objet global

Les conteneurs Webtask serverless d’Auth0 sont provisionnés à partir d’un bassin associé à chaque tenant Auth0. Tous les scripts d’action qui s’exécutent dans une instance de conteneur peuvent accéder à l’objet global, qui agit comme une variable globale propre au conteneur.

Vous pouvez utiliser l’objet global pour définir des informations ou des fonctions utilisées par tous les scripts d’action qui s’exécutent dans l’instance de conteneur, ou pour mettre en cache des ressources coûteuses, par exemple en y stockant un jeton d’accès pour une API de journalisation tierce ou pour votre propre API définie dans Auth0 et obtenue au moyen du flux Client Credentials.

Ne stockez pas d’informations propres à l’utilisateur dans l’objet global. Comme il n’y a pas d’affinité de conteneur pour l’exécution des scripts d’action dans Auth0, les scripts d’action peuvent s’exécuter dans n’importe quelle instance de conteneur active ou dans une nouvelle instance de conteneur ajoutée au bassin.

Toutes les déclarations d’affectation dans l’objet global doivent également prévoir une initialisation, car l’objet global est réinitialisé lorsqu’un conteneur Webtask est recyclé ou instancié.

​

Objet configuration

Vous pouvez définir des paramètres de configuration dans les scripts d’action de base de données afin de rendre certaines valeurs accessibles à tous les scripts par l’intermédiaire de l’objet configuration. Les valeurs sont chiffrées.

Considérez l’objet configuration comme étant en lecture seule et utilisez-le pour éviter d’intégrer des valeurs en dur dans vos scripts d’action. Par exemple, vous pouvez y stocker des renseignements sensibles, comme des identifiants ou des clés API permettant d’accéder à des magasins d’identités externes, ou définir des variables contenant des valeurs propres au tenant.

​

Objet context

Si vous utilisez les organisations, vous pouvez rendre les données de l’organisation accessibles à vos scripts d’action de base de données en activant l’objet context. Un argument context supplémentaire contenant des informations sur l’organisation, telles que id, name et metadata, est alors transmis aux scripts de base de données personnalisée.

Vous ne pouvez pas désactiver l’objet context une fois qu’il est activé. Le script Delete reçoit toujours un objet context vide.

​

Limites

• La taille totale d’un script d’action ne doit pas dépasser 100 Ko, sans compter les modules npm importés. Des scripts plus volumineux entraînent une latence accrue en raison du processus d’empaquetage et de transport de la plateforme Webtask, ce qui nuit aux performances du système.

• Le conteneur Webtask de chaque script d’action est soumis à une limite d’exécution d’environ 20 secondes, après quoi il est recyclé. Cela met fin aux opérations en attente du script d’action et peut entraîner des erreurs.