Cuentas de prueba y sesión autenticada

Un escáner autenticado ve lo que ve el usuario cuya sesión usa. Con una sola cuenta de asociado cubre las páginas de asociado; las de asesor no existen para él. Por eso se le da una cuenta por rol que se quiera cubrir, y por eso esas cuentas se crean para el encargo, con datos sintéticos: el escáner va a llenar formularios, cambiar datos de contacto y pedir créditos con ellas.

Dos cuentas no sirven nunca: la de una persona real, porque sus datos acaban en informes y sus avisos le llegan a ella; y una de administración que la autorización no cubre, porque multiplica lo que el escáner puede romper. Las claves no van en los archivos de configuración: viven en una bóveda y se citan por referencia.

Abre el laboratorio y lee cuentas-de-prueba.txt. Las copias de producción a preproducción son una fuente clásica de datos reales donde nadie los espera: traen usuarios, correos y teléfonos de personas de verdad. Una cuenta que parece de prueba porque vive en preproducción puede no serlo.

El escáner ingresa una vez con el formulario y guarda la cookie. Si la sesión caduca, cada página interna responde con una redirección al ingreso, y el escáner sigue trabajando… sobre la página de ingreso. Para notarlo usa dos indicadores: un texto que solo aparece con la sesión iniciada y otro que solo aparece con la sesión cerrada. Con ellos sabe cuándo volver a ingresar.

Lee politica-sesion.txt y luego registro-escaneo.txt. Busca la primera respuesta que manda al ingreso.

Perder la sesión es normal; quedarse fuera el resto de la noche, no. Compara el indicador de sesión iniciada de contexto-autenticacion.txt con las dos páginas de paginas.txt, y fíjate en qué campo está vacío.

Un informe con pocas alertas en las páginas internas no dice «las páginas internas están bien»: puede decir «el escáner no las vio». Antes de leer las alertas hay que saber qué parte del trabajo se hizo con sesión. El resumen del registro tiene los dos números que hacen falta.