Utilisation
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 :
callback sans paramètre, comme dans callback(), revient à l’appeler avec callback(null).
JavaScript asynchrone
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
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
Objet global
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 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.global doivent également prévoir une initialisation, car l’objet global est réinitialisé lorsqu’un conteneur Webtask est recyclé ou instancié.
Objet configuration
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
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
npmimporté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.