Autenticación y mensajes

Muchos recorridos importantes salen del navegador: enlaces mágicos, códigos OTP, correos de bienvenida, recibos, verificación por SMS y restablecimientos de contraseña. Autonomy mantiene esos mensajes adjuntos a la misma ejecución que la sesión de navegador o móvil.

Bandejas de entrada

Las bandejas de entrada generadas son útiles para comprobaciones desechables de registro, invitación y recibo. Las bandejas de entrada estáticas son mejores cuando un proveedor de autenticación rechaza dominios desechables, cuando un tenant de staging tiene usuarios precargados, o cuando un sistema de terceros debe aprobar una dirección fija.

Mecanismos de verificación por correo

Configura cómo el agente supera las pantallas de verificación por correo en Configuración → Integraciones → Verificación de correo (valor predeterminado del workspace), o por entorno desde la configuración del entorno. Las anulaciones por entorno tienen prioridad sobre el valor predeterminado del workspace.

Bandejas alojadas (predeterminado)

Autonomy genera una dirección desechable por ejecución y lee el correo real: funcionan tanto los códigos OTP como los enlaces mágicos, sin configuración. Úsalo salvo que tu aplicación restrinja los dominios de registro.

Modo de prueba (código estático)

Para aplicaciones que solo aceptan dominios aprobados — por ejemplo, un entorno de desarrollo que rechaza toda dirección fuera de tu dominio corporativo. Tu backend trata las direcciones con plantilla como usuarios de prueba con un código de verificación fijo, y Autonomy sirve ese código sin entrega real de correo. Es el mismo patrón que las direcciones +clerk_test de Clerk (OTP fijo 424242) y los números de teléfono ficticios de Firebase.

• Plantilla de dirección — p. ej. qa+{token}@tuempresa.com. {token} se convierte en un slug aleatorio por ejecución para que los registros paralelos nunca colisionen. Una plantilla sin {token} se rechaza salvo que existan direcciones de prueba fijas, porque una dirección fija rompe la segunda ejecución con «correo ya registrado».
• Direcciones de prueba — cuentas fijas en las que tus casos de prueba inician sesión con credenciales guardadas. El código estático también se aplica a ellas, así que un inicio de sesión que dispara un OTP por correo pasa sin ninguna bandeja.
• Código estático — el código fijo que tu backend acepta para estas direcciones. Se guarda en modo solo escritura, como el resto de secretos.

El cambio único en tu backend: fuera de producción, trata las direcciones que coinciden con la plantilla como usuarios de prueba — acepta el código fijo y omite el envío real.

El modo de prueba solo sirve códigos. Los flujos que verifican mediante enlace mágico necesitan entrega real: usa bandejas alojadas o tu propio dominio.

Tu dominio (puente)

Entrega real en un dominio de tu propiedad: funcionan los códigos y los enlaces mágicos, en un dominio aprobado por la lista blanca, sin cambios en el backend. Autonomy genera direcciones cortas como r-a1b2c3d4@qa.tuempresa.com por ejecución.

Configuración (administrador del workspace, en los ajustes de Verificación de correo):

1. Añade un subdominio dedicado (p. ej. qa.tuempresa.com): su reenvío catch-all enviará todo su correo a Autonomy.
2. Demuestra la propiedad: añade el registro TXT mostrado en los ajustes (_autonomy-challenge.qa.tuempresa.com → autonomy-verify=…) y pulsa Verificar.
3. Reenvía el correo: configura un reenvío catch-all del subdominio a la dirección de ingesta de tu workspace (mostrada en los ajustes). Funciona con Cloudflare Email Routing, el enrutamiento de Google Workspace o las reglas de transporte de Microsoft 365. Si tu proveedor envía un correo de confirmación del reenvío a la dirección de ingesta, su enlace aparece en el panel de ajustes.
4. Activa: envía cualquier correo a test@qa.tuempresa.com. El primer correo reenviado prueba el puente y lo activa automáticamente.

Las cuentas de prueba fijas del dominio puente pueden listarse como direcciones de prueba: sus correos de verificación son legibles por todas las ejecuciones del ámbito, así que los OTP y enlaces mágicos de inicios de sesión con credenciales guardadas también funcionan.

Las ejecuciones fallan con un error accionable mientras el puente no esté verificado o activo: no hay retroceso silencioso a bandejas alojadas, porque una dirección alojada sería rechazada por la misma lista blanca de dominios que te llevó a configurar el puente.

Elegir un mecanismo

OTP

Autonomy puede esperar mensajes OTP por correo, extraer el código y continuar el flujo. Mantén las esperas de OTP acotadas nombrando el remitente, el asunto y la forma esperada del código para que la ejecución no use por accidente un mensaje antiguo o no relacionado.

SMS

Usa comprobaciones de SMS para flujos de verificación que no se pueden ejercitar por correo. Trata los números de SMS como recursos de prueba: documenta quién los posee, qué entornos pueden usarlos y cuándo deben rotarse.

Previsualizaciones protegidas

Para previsualizaciones protegidas, documenta el token de omisión o la contraseña de previsualización como variable de entorno, no en el cuerpo del caso de prueba.

Solución de problemas

No llega ningún mensaje

Comprueba la dirección o el número del destinatario, las restricciones del remitente, la configuración de correo específica del entorno y si el proveedor suprime los mensajes para los dominios de prueba.

Se usa el código equivocado

Ajusta las restricciones de remitente, asunto y marca de tiempo. Las comprobaciones de OTP deben esperar un mensaje nuevo creado durante la ejecución, no el mensaje más reciente de la bandeja de entrada.