Passer au contenu principal

La disponibilité varie selon le forfait Auth0

Votre forfait Auth0 ou votre entente personnalisée détermine si cette fonctionnalité est offerte. Pour en savoir plus, consultez les tarifs.
Si vous avez votre propre base de données (appelée magasin de données hérité dans Auth0) qui contient des données d’identité utilisateur, vous pouvez l’utiliser comme pour authentifier les utilisateurs. Vous créez et configurez la connexion à votre magasin de données hérité comme une 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ée vers le magasin de données d’Auth0, ou continuer à l’utiliser sans migrer les données. Nous fournissons des modèles de scripts pour exécuter des fonctions 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ée :
  • Migration automatique : Chaque fois qu’un utilisateur se connecte à Auth0, s’il n’y est pas encore, le script vérifie dans la base de données héritée si cet utilisateur s’y trouve. S’il est trouvé et que l’option Importer les utilisateurs dans Auth0 est activée, les données de l’utilisateur sont migrées vers le magasin de données d’Auth0. Cette fonctionnalité est parfois appelée migration progressive ou migration paresseuse.
  • Base de données héritée : Auth0 interroge toujours la base de données sous-jacente lorsqu’un utilisateur tente de se connecter, est créé, change son mot de passe, vérifie son courriel ou est supprimé. S’il 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ée et ne sont pas migrées vers Auth0.
Auth0 fournit les scripts d’action de base de données personnalisée suivants :

Pare-feu réseau

Si vous êtes derrière un pare-feu, cette fonctionnalité peut exiger que vous ajoutiez les adresses IP Auth0 appropriées à la liste d’autorisation pour fonctionner correctement.

​
Exécution des scripts

Comme indiqué 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 : du code personnalisé utilisé pour interagir avec votre référentiel d’identités hérité. Chaque script d’action est essentiellement une fonction JavaScript nommée à laquelle divers paramètres sont passés; le nom de la fonction et les paramètres varient selon le script.

​
Limites

L’exécution des scripts d’action prend en charge la nature asynchrone de JavaScript, et des structures comme les objets Promise peuvent être utilisées. Le traitement asynchrone entraîne concrètement une suspension jusqu’à ce qu’une opération soit terminée, et un conteneur Webtask sans serveur d’Auth0 a généralement une limite d’exécution de 20 secondes, après quoi il peut être recyclé. Si un conteneur est recyclé en raison de cette limite, l’opération prendra fin prématurément, ce qui se traduira au final par le renvoi d’une erreur (et potentiellement par la réinitialisation de l’objet global).

​
Fin de l’exécution et fonction de rappel

La fonction callback fournie à chaque script d’action agit comme un signal indiquant que l’opération est terminée. Un script d’action doit se terminer immédiatement après l’appel à la fonction callback (soit implicitement, soit en exécutant explicitement une instruction JavaScript return) et ne doit effectuer aucune autre opération.
La fonction callback fournie par Auth0 doit être appelée exactement une fois; l’appeler 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ée sans paramètre, comme dans callback(), cela signifie 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 reporté jusqu’à la fin de ce traitement et doit être la toute dernière chose exécutée. En exécution asynchrone, un callback JavaScript est exécuté une fois l’opération asynchrone terminée; ce rappel est généralement déclenché après l’exécution du corps principal (synchrone) d’une fonction JavaScript.
Si la fonction callback n’est pas exécutée, l’exécution restera bloquée et finira par retourner une erreur. Le script d’action doit appeler la fonction callback exactement une fois : elle doit être appelée au moins une fois pour éviter le blocage de l’exécution, mais pas plus d’une fois, faute de quoi des résultats imprévisibles et/ou des erreurs se produiront.