Marque la tentative en cours de réinitialisation du mot de passe comme refusée. Cela empêchera l’utilisateur de terminer
le flux de réinitialisation du mot de passe. Cela N’ANNULERA PAS les autres effets secondaires liés à l’utilisateur
demandés par cette Action. Le flux de réinitialisation du mot de passe s’arrêtera immédiatement après
l’exécution de cette action, et aucune autre Action ne sera exécutée.
Demande un défi d’authentification multifacteur à l’aide du facteur fourni et, au besoin, de facteurs additionnels.Lorsqu’un défi multifacteur est demandé, les Actions suivantes ne s’exécuteront pas tant que l’utilisateur n’aura pas
réussi ce défi. Un utilisateur aura satisfait au défi dans l’une ou l’autre des situations suivantes :
Il réussit le défi pour le facteur par défaut.
Il réussit le défi pour l’un des facteurs facultatifs décrits dans additionalFactors.
Si l’un des facteurs demandés a déjà été validé avec succès dans la transaction en cours, il sera
ignoré.Si un facteur demandé n’est pas activé pour le locataire, il sera ignoré. Si un facteur demandé n’a pas été
inscrit par l’utilisateur, il sera ignoré. Si aucun des facteurs demandés n’est activé ou inscrit, la transaction
d’authentification échouera (c.-à-d. que la connexion ne se terminera pas).
Cette méthode affichera un écran de défi de facteur si l’utilisateur n’a pas déjà satisfait
aux exigences du défi. Si additionalFactors est fourni, l’utilisateur pourra
sélectionner un autre facteur s’il le souhaite.
Demandez un défi d’authentification multifacteur à l’aide de l’un des facteurs fournis (en affichant d’abord un écran
de sélection du facteur).Lorsqu’un défi multifacteur est demandé, les Actions suivantes ne s’exécutent pas tant que ce défi n’a pas été
rempli par l’utilisateur. Un utilisateur aura satisfait au défi dans l’un ou l’autre des cas suivants :
Il réussit le défi pour l’un des facteurs.
Si l’un des facteurs demandés a déjà fait l’objet d’un défi réussi dans la transaction en cours, il sera
ignoré.Si un facteur demandé n’est pas activé pour le locataire, il sera ignoré. Si un facteur demandé n’est pas
inscrit pour l’utilisateur, il sera ignoré. Si aucun des facteurs demandés n’est activé ou inscrit, la
transaction d’authentification échouera (c.-à-d. que la connexion ne se terminera pas).
Cette méthode affichera l’écran de sélection du facteur si l’utilisateur n’a pas déjà satisfait
aux exigences du défi. S’il existe un facteur privilégié, il est préférable d’utiliser la méthode api.authentication.challengeWith().
L’écran de sélection du facteur ne s’affichera pas si un seul facteur est transmis ou valide.
Créez un jeton de session pouvant être utilisé comme paramètre de chaîne de requête pour une redirection (via sendUserTo) et
contenant des données dont l’authenticité doit pouvoir être prouvée par le point de terminaison cible. Le point de terminaison cible
peut vérifier l’authenticité et l’intégrité des données en validant la signature du JWT
à l’aide d’un secret partagé.Le secret partagé doit être stocké comme secret de l’Action et sera accessible dans
event.secrets['<secret_name>'].
Un secret utilisé pour signer un JWT partagé avec la cible de redirection. La
valeur du secret doit être stockée comme secret et récupérée à l’aide de
event.secrets['<secret_name>'].
Déclenche une redirection du navigateur vers l’url cible dans le pipeline de réinitialisation du mot de passe, immédiatement après
la fin de cette action. La méthode utilitaire createUrl est fournie pour simplifier l’encodage des
données en tant que paramètre de requête dans l’url cible, afin que l’authenticité et
l’intégrité des données puissent être vérifiées par le point de terminaison cible.
Récupère un Record décrivant une valeur mise en cache à la clé fournie,
s’il existe. Si un Record est trouvé, la valeur mise en cache se trouve
dans la propriété value de l’objet retourné.
Stocke ou met à jour une valeur de chaîne dans le cache pour la clé spécifiée.Les valeurs stockées dans ce cache sont limitées au déclencheur dans lequel
elles sont définies. Elles sont assujetties aux Actions Cache Limits.Les valeurs stockées de cette façon auront une durée de vie pouvant aller jusqu’aux
valeurs spécifiées pour ttl ou expires_at. Si aucune durée de vie n’est spécifiée, une durée de vie
par défaut de 15 minutes sera utilisée. Les durées de vie ne peuvent pas dépasser la durée maximale
indiquée dans Actions Cache Limits.Important : Ce cache est conçu pour des données éphémères de courte durée. Il se peut que des éléments ne soient pas
disponibles dans des transactions ultérieures, même si leur durée de vie n’est pas encore expirée.
La date d’expiration absolue en millisecondes depuis l’époque Unix.
Bien que les Records mis en cache puissent être évincés plus tôt, ils ne
seront jamais conservés au-delà de la valeur expires_at fournie.Remarque : Cette valeur ne doit pas être fournie si une valeur a aussi été
fournie pour ttl. Si les deux options sont fournies, la
plus rapprochée des deux expirations sera utilisée.
La durée de vie de cette entrée de cache en millisecondes.
Bien que les valeurs mises en cache puissent être évincées plus tôt, elles ne
seront jamais conservées au-delà de la valeur ttl fournie.Remarque : Cette valeur ne doit pas être fournie si une valeur a aussi été
fournie pour expires_at. Si les deux options sont fournies, la
plus rapprochée des deux expirations sera utilisée.