Modèles de scripts d’action personnalisés pour la base de données
La disponibilité varie selon le plan Auth0
Votre plan Auth0 ou votre accord personnalisé ont un impact sur la disponibilité de cette fonctionnalité. Pour en savoir plus, lisez Tarification.
Si vous disposez de votre propre base de données (appelée legacy data store [stockage de données héritées] dans Auth0) contenant les données d’identité des utilisateurs, vous pouvez l’utiliser comme fournisseur d’identité pour authentifier les utilisateurs. Vous créez et configurez la connexion à votre stockage de données héritées en tant que base de données personnalisée dans Auth0. Vous pouvez choisir de migrer progressivement les données de votre base de données héritées vers le stockage de données d’Auth0, ou vous pouvez continuer à l’utiliser sans migrer les données. Nous fournissons des modèles de scripts pour exécuter des performances sur la base de données personnalisée que vous pouvez utiliser et personnaliser.
Il existe deux types de scripts de base de données personnalisés :
Migration automatique : Si un utilisateur se connecte à Auth0 et qu’il n’est pas encore dans Auth0, le script vérifie si l’utilisateur existe dans la base de données héritées. Si l’utilisateur est trouvé et que l’option Importer les utilisateurs dans Auth0 est activée, les données de l’utilisateur migrent vers le stockage de données d’Auth0. Cette capacité est parfois appelée migration au compte-gouttes ou migration paresseuse.
Base de données héritées : Auth0 sollicitera toujours la base de données sous-jacente lorsqu’un utilisateur tente de se connecter, est créé, modifie son mot de passe, vérifie son courriel ou est supprimé. Si l’utilisateur est trouvé et que l’option Importer les utilisateurs dans Auth0 n’est pas activée, les données de l’utilisateur restent dans la base de données héritées et ne migrent pas vers Auth0.
Auth0 fournit les scripts d’action personnalisés suivants pour la base de données :
Pare-feu réseau
Si vous êtes derrière un pare-feu, cette fonctionnalité pourrait exiger que vous ajoutiez les adresses IP Auth0 appropriées à votre Liste blanche pour que cela fonctionne correctement.
Exécution des scripts
Comme décrit dans Connexions de base de données personnalisées, un type de connexion de base de données personnalisée vous permet de configurer des scripts d’action : un code personnalisé utilisé lors de l’interface avec votre magasin d’identités hérité. Chaque script d’action est essentiellement une fonction JavaScript nommée à laquelle est transmis un certain nombre de paramètres, le nom de la fonction et les paramètres transmis dépendant du script.
Limites
L’exécution des scripts d’action prend en charge la nature asynchrone de JavaScript, et des constructions telles que les objets Promise peuvent être utilisées. Le traitement asynchrone se traduit effectivement par une suspension en attendant la fin d’une opération, et un conteneur Webtask sans serveur Auth0 a généralement une limite d’exécution de 20 secondes, après quoi le conteneur peut être recyclé. Le recyclage d’un conteneur en raison de cette limite mettra fin prématurément à l’opération, ce qui entraînera le renvoi d’une condition d’erreur (ainsi qu’une réinitialisation potentielle de l’objet global).
Achèvement et fonction Callback
La fonction callback fournie à chaque script d’action agit concrètement comme un signal indiquant la fin de l’opération. Un script d’action doit se terminer immédiatement après un appel à la fonction callback (soit implicitement, soit en exécutant explicitement une instruction de retour JavaScript) et doit s’abstenir de toute autre opération.
La fonction callback (Rappel) fournie par Auth0 ne doit être appelée qu’une fois. Appeler la fonction plus d’une fois dans un script d’action entraînera des résultats imprévisibles et/ou des erreurs.
Lorsque callback est exécuté sans paramètres, comme dans callback(), cela implique que la fonction a été appelée comme si callback(null) avait été exécutée.
Si un script d’action utilise un traitement asynchrone, l’appel à la fonction callback doit être différé jusqu’à la fin du traitement asynchrone et doit être le dernier élément appelé. L’exécution asynchrone entraîne l’exécution d’un callback JavaScript après la fin de l’opération asynchrone; ce callback est généralement déclenché à un moment donné après la fin du corps principal (synchrone) d’une fonction JavaScript.
Défaut d’exécution de la fonction callback entraînera un blocage de l’exécution et, en fin de compte, une condition d’erreur renvoyée. Le script d’action doit appeler la fonction callback fonctionne exactement une fois : la fonction callback doit être appelée au moins une fois afin d’éviter le blocage de l’exécution, cependant elle ne doit pas être appelée plus d’une fois sinon des résultats imprévisibles et/ou des erreurs se produiront.