Authentification et messages

De nombreux parcours importants sortent du navigateur : liens magiques, codes OTP, e-mails de bienvenue, reçus, vérification par SMS et réinitialisations de mot de passe. Autonomy garde ces messages rattachés à la même exécution que la session navigateur ou mobile.

Mécanismes de vérification par e-mail

Configurez la façon dont l'agent franchit les écrans de vérification par e-mail dans Paramètres → Intégrations → Vérification e-mail (valeur par défaut du workspace), ou par environnement depuis les paramètres de l'environnement. Les surcharges par environnement priment sur la valeur par défaut du workspace.

Boîtes hébergées (par défaut)

Autonomy génère une adresse jetable par exécution et lit le vrai e-mail : les codes OTP et les liens magiques fonctionnent, sans aucune configuration. À utiliser sauf si votre application restreint les domaines d'inscription.

Mode test (code statique)

Pour les applications qui n'acceptent que des domaines approuvés — par exemple un environnement de développement qui rejette toute adresse hors de votre domaine d'entreprise. Votre backend traite les adresses issues du modèle comme des utilisateurs de test avec un code de vérification fixe, et Autonomy sert ce code sans aucune livraison réelle d'e-mail. C'est le même schéma que les adresses +clerk_test de Clerk (OTP fixe 424242) et les numéros de téléphone fictifs de Firebase.

• Modèle d'adresse — p. ex. qa+{token}@votreentreprise.com. {token} devient un slug aléatoire par exécution afin que les inscriptions parallèles n'entrent jamais en collision. Un modèle sans {token} est rejeté sauf si des adresses de test fixes existent, car une adresse fixe casse la deuxième exécution avec « e-mail déjà enregistré ».
• Adresses de test — comptes fixes dans lesquels vos cas de test se connectent avec des identifiants stockés. Le code statique s'applique aussi à ces adresses : une connexion qui déclenche un OTP par e-mail passe sans aucune boîte.
• Code statique — le code fixe que votre backend accepte pour ces adresses. Stocké en écriture seule, comme les autres secrets.

Le changement unique côté backend : hors production, traitez les adresses correspondant au modèle comme des utilisateurs de test — acceptez le code fixe et sautez l'envoi réel.

Le mode test ne sert que des codes. Les flux qui vérifient via lien magique nécessitent une livraison réelle : utilisez les boîtes hébergées ou votre propre domaine.

Votre domaine (pont)

Livraison réelle sur un domaine que vous possédez : les codes et les liens magiques fonctionnent, sur un domaine approuvé par la liste blanche, sans modification du backend. Autonomy génère des adresses courtes comme r-a1b2c3d4@qa.votreentreprise.com par exécution.

Configuration (administrateur du workspace, dans les paramètres de Vérification e-mail) :

1. Ajoutez un sous-domaine dédié (p. ex. qa.votreentreprise.com) : son transfert catch-all enverra tout son courrier à Autonomy.
2. Prouvez la propriété : ajoutez l'enregistrement TXT affiché dans les paramètres (_autonomy-challenge.qa.votreentreprise.com → autonomy-verify=…), puis cliquez sur Vérifier.
3. Transférez le courrier : configurez un transfert catch-all du sous-domaine vers l'adresse d'ingestion de votre workspace (affichée dans les paramètres). Fonctionne avec Cloudflare Email Routing, le routage Google Workspace ou les règles de transport Microsoft 365. Si votre fournisseur envoie un e-mail de confirmation du transfert à l'adresse d'ingestion, son lien apparaît dans le panneau des paramètres.
4. Activez : envoyez n'importe quel e-mail à test@qa.votreentreprise.com. Le premier e-mail transféré prouve le pont et l'active automatiquement.

Les comptes de test fixes du domaine pont peuvent être listés comme adresses de test : leurs e-mails de vérification sont lisibles par toutes les exécutions du périmètre, donc les OTP et liens magiques des connexions à identifiants stockés fonctionnent aussi.

Les exécutions échouent avec une erreur actionnable tant que le pont n'est pas vérifié ou actif : aucun repli silencieux vers les boîtes hébergées, car une adresse hébergée serait rejetée par la même liste blanche de domaines qui vous a fait configurer le pont.

Choisir un mécanisme

Boîtes de réception

Les boîtes de réception générées sont utiles pour les vérifications jetables d'inscription, d'invitation et de reçu. Les boîtes de réception statiques sont préférables lorsqu'un fournisseur d'authentification rejette les domaines jetables, lorsqu'un locataire de préproduction a des utilisateurs préchargés, ou lorsqu'un système tiers doit approuver une adresse fixe.

OTP

Autonomy peut attendre les messages OTP par e-mail, extraire le code et poursuivre le flux. Gardez les attentes OTP étroites en nommant l'expéditeur, l'objet et la forme attendue du code afin que l'exécution n'utilise pas accidentellement un message ancien ou sans rapport.

SMS

Utilisez les vérifications SMS pour les flux de vérification qui ne peuvent pas être exercés par e-mail. Traitez les numéros SMS comme des ressources de test : documentez qui les possède, quels environnements peuvent les utiliser et quand ils doivent être renouvelés.

Prévisualisations protégées

Pour les prévisualisations protégées, documentez le jeton de contournement ou le mot de passe de prévisualisation en tant que variable d'environnement, et non dans le corps du cas de test.

Dépannage

Aucun message n'arrive

Vérifiez l'adresse ou le numéro du destinataire, les restrictions d'expéditeur, les paramètres d'e-mail spécifiques à l'environnement, et si le fournisseur supprime les messages pour les domaines de test.

Le mauvais code est utilisé

Resserrez les contraintes d'expéditeur, d'objet et d'horodatage. Les vérifications OTP doivent attendre un nouveau message créé pendant l'exécution, et non le message le plus récent de la boîte de réception.