ResidApp · Plataforma Asistencial Geriátrica

ResidApp · Acceso y sesión

Cómo se entra en ResidApp: el acceso y la sesión

Estado a 24/10/2026 · Para quien usa o prueba la aplicación, para Plataforma y soporte, y para quien responde de su seguridad

Nadie se crea su propia cuenta en ResidApp: el acceso lo da quien responde de cada persona. Después, cada vez que abres una pantalla, la aplicación comprueba quién eres, con tu sesión, y qué puedes hacer, con el perfil, el centro y las unidades de tu cuenta. Se entra con tu identificador y tu contraseña y, si eres del personal, con un código de tu móvil (segundo factor), o con una passkey («llave de acceso»: una credencial guardada en tu móvil o portátil que se desbloquea con tu huella, tu cara o tu PIN) si la has registrado. La contraseña la eliges tú con la invitación de un solo uso que te entrega tu Administración. En el entorno de pruebas se entra exactamente igual: desde el 24/10/2026 no hay otra forma de entrar.

Lo esencial

Cómo se pide el acceso

Cada cuenta la da de alta quien responde de esa persona, y nadie más. Se pide fuera de la aplicación (en persona, por teléfono o por el canal de cada centro) y no hay formulario de solicitud: el enlace «Cómo pedir el acceso» de la pantalla de acceso solo lo explica.

Quién da el acceso a quién Quien administra la base de datos crea, una sola vez y por SQL, la cuenta de Plataforma. Plataforma crea cada centro nuevo con su primera Administración y después le da soporte: marca la Administración principal y añade unidades a su ámbito. La Administración del centro da de alta al personal (Auxiliar, Enfermería, Medicina, Dirección Clínica y otras Administraciones) y da a las familias el acceso al Portal Familiar, que solo vale con la autorización activa. crea crea alta acceso soporte: principal y unidades Base de datos quien la administra, una vez y por SQL RAÍZ DE CONFIANZA Plataforma crea el centro y su primera Administración PLATAFORMA · SOPORTE Administración da de alta al personal y el acceso de la familia ADMINISTRACIÓN Personal del centro Auxiliar, Enfermería, Medicina, Dirección Clínica, Administración «ALTA DE USUARIO» Familia «Dar acceso al portal» y la autorización activa FAMILIA

Quién da de alta y entrega la invitación

Si eres…Lo pides a…Qué hace quien te lo daCon qué entras
Personal de un centro: Auxiliar, Enfermería, Medicina, Dirección Clínica u otra Administración La Administración de tu centro En «Usuarios», Alta de usuario: tu identificador de acceso, tu nombre, tu perfil y tus unidades. Después, en tu ficha, Crear invitación de acceso, y te entrega la hoja. Tu identificador, tu contraseña y el código del móvil, o tu passkey
Familiar de un residente La Administración del centro En la ficha del residente, «Autorización» → Dar acceso al portal con tu usuario y, debajo, Crear invitación de acceso. Después abre y activa la autorización: sin ella activa, no ves a nadie. Tu usuario y tu contraseña
La primera Administración de un centro nuevo Plataforma, el soporte de ResidApp Nuevo centro: el centro, su primera unidad y tu cuenta de Administración, todo a la vez. Después, en el centro, Crear invitación de acceso o de recuperación. Tu identificador, tu contraseña y el código del móvil, o tu passkey
Operador de Plataforma Quien administra la base de datos Crea la cuenta y su ámbito por SQL, una sola vez, y le da su invitación con el script database/operaciones/invitar_cuenta.sql. No hay pantalla, a propósito: es la cuenta más sensible. Tu passkey: en cuanto tienes una, es la única forma de entrar. Hasta entonces, tu contraseña y el código del móvil
Quien prueba la aplicación (CJ) Orlando Las cuentas de prueba ya existen, sin contraseña. Orlando te entrega la invitación de cada una, como Plataforma y como Administración harían en un centro real. Cada cuenta de prueba con su contraseña y su código del móvil, o su passkey

La invitación y la recuperación (incremento I2)

Así recibe cada persona su contraseña (ADR 0007, hecho el 22/10/2026):

  1. 1Administración o Plataforma

    Da de alta la cuenta: Administración al personal y a las familias, Plataforma a la primera Administración de un centro nuevo. La cuenta nace sin contraseña.

  2. 2Administración o Plataforma

    Entrega una invitación de un solo uso: una hoja con un código QR y su dirección, en mano o en su pantalla. Vale 72 horas; solo se ve al crearla, y crear otra anula la anterior. No hace falta que la persona tenga correo.

  3. 3La persona

    Abre la invitación y elige su contraseña; la invitación deja de valer. Si es del personal, ahí mismo prepara el segundo factor (una app de códigos en el móvil, TOTP) y guarda sus 10 códigos de recuperación. Es el único sitio donde se prepara: saber la contraseña de alguien no basta para registrar otro móvil.

    Desde entonces entra con su identificador, su contraseña y el código del móvil.

  4. 4Administración

    Si olvida la contraseña o pierde el móvil, la persona lo pide a su Administración, que le entrega una invitación de recuperación. Al usarla elige otra contraseña, prepara de nuevo el segundo factor y se cierran todas sus sesiones: recuperar el acceso nunca deja la cuenta con menos protección. Hasta que la usa, su contraseña de siempre sigue valiendo.

  5. 5La persona

    En «Mi cuenta» cambia su contraseña, genera códigos de recuperación nuevos, registra o quita sus passkeys y ve y cierra sus sesiones abiertas. Para cambiar de móvil necesita una invitación de recuperación (paso 4), que además borra sus passkeys.

Las cuentas de Plataforma entran solo con passkey en cuanto tienen una (I4). El segundo factor de las familias está por decidir con CJ.

Qué hace Plataforma o soporte

Plataforma es el perfil de quien opera ResidApp; hoy, el soporte lo da Orlando. Crea centros y ayuda a sus Administraciones, pero no ve residentes ni nada clínico y no da de alta al personal de un centro: eso es siempre de su Administración. Todo lo que hace queda en la auditoría.

Lo que soporte no hace nunca

  • Pedir ni apuntar contraseñas o códigos de nadie, tampoco cuando existan.
  • Dar de alta al personal de un centro en lugar de su Administración, ni entrar con la cuenta de otra persona para «probar».
  • Mirar datos de residentes: Plataforma no puede, y nadie le pasa capturas con ellos.

Las invitaciones: Plataforma entrega la de la primera Administración de cada centro nuevo (y la recuperación de una Administración que no tiene otra que se la dé); la Administración de cada centro, las del resto de cuentas y sus recuperaciones. Nadie se entrega una invitación a sí mismo.

Cada vez que abres una pantalla

Las comprobaciones van en este orden y en todas las pantallas, también al guardar. Si una falla, la pantalla no se muestra. La sesión se comprueba contra la base de datos en cada paso: si se cerró en otro sitio, se nota en ese mismo momento.

Las cuatro comprobaciones de cada pantalla Abres una pantalla. Primera comprobación: si es pública, se muestra sin pedir sesión. Si no lo es, segunda: si no traes una sesión válida (abierta, en uso y sin caducar), vas a la pantalla de acceso y, al entrar, vuelves. Con sesión, tercera: si no has elegido ámbito, lo eliges cuando tienes más de uno. Con ámbito, cuarta: si tu perfil puede hacerlo, se muestra la pantalla con los datos de tu centro; si no, se deniega con un aviso. no sí sí sí sí no no no al entrar Abres una pantalla o guardas algo 1 · ¿Es pública? Inicio, Manual, Flujo… 2 · ¿Sesión válida? abierta, en uso, sin caducar 3 · ¿Ámbito elegido? perfil, centro y unidades 4 · ¿Tu perfil puede? permisos y datos del centro Se muestra sin pedir sesión Se muestra solo con tu centro Pantalla de acceso usuario y clave Eliges ámbito si tienes más de uno Se deniega con un aviso

En el móvil, desliza el diagrama hacia los lados. Una sesión válida está abierta, se ha usado en los últimos 30 minutos, no han pasado 12 horas desde que entraste y la cuenta sigue activa.

Entrar

En «Iniciar sesión» escribes tu usuario y tu contraseña y pulsas «Entrar». Llegas a ella al abrir una pantalla sin sesión, con «Iniciar sesión» en la cabecera o con «Entrar con otra cuenta» en la pantalla de elegir ámbito. Si eres del personal (cualquier perfil salvo el de familiar), después te pide el código de 6 cifras de tu aplicación de autenticación, que preparaste al usar tu invitación. Si no lo llegaste a preparar, la pantalla te pide una invitación nueva.

Si has registrado una passkey, pulsas «Entrar con passkey» sin escribir nada: el dispositivo te pide la huella, la cara o el PIN y entras. Es una entrada completa, sin contraseña ni código del móvil, y solo funciona en la dirección web de ResidApp, así que una página falsa que imite a ResidApp no puede aprovecharla. Una cuenta bloqueada por intentos, suspendida o sin ámbito activo tampoco entra con passkey. Las cuentas de Plataforma entran solo con passkey en cuanto tienen una; sin ninguna, su primer acceso con contraseña y código las lleva a «Mi cuenta» a crear la primera. Cómo se añade una, paso a paso, está en Passkeys.

Qué pasa al pulsar «Entrar» Escribes el usuario y la contraseña y, si eres del personal, el código de tu móvil. Si la contraseña o el código no son correctos, o la cuenta no existe, está suspendida, bloqueada o no tiene ningún ámbito activo, no entras y sigues como estabas. Si son correctos, se cierra la sesión que tuvieras abierta, se abre una nueva y, si la cuenta tiene un solo ámbito, llegas a tu inicio o a la pantalla a la que ibas; si tiene varios, eliges antes con cuál trabajas. Cinco fallos seguidos bloquean la cuenta 15 minutos, y desde una misma conexión se frenan los fallos repetidos en muchas cuentas. sí no uno varios Usuario y contraseña el personal, y su código ¿Son correctos? y cuenta con ámbito Cierra la anterior si tenías otra sesión Abre la sesión 30 min sin uso · 12 h ¿Cuántos ámbitos? perfil y centro Tu inicio o adonde ibas Eliges ámbito y después, tu inicio No entras sigues como estabas Límite de intentos 5 fallos: 15 min

Passkeys: qué son, qué necesitas y cómo se usan

Una passkey («llave de acceso») es la forma más cómoda de entrar: no escribes usuario, contraseña ni código del móvil, solo te verificas con la huella, la cara o el PIN del dispositivo. Por dentro son dos claves que crea tu dispositivo: la secreta nunca sale de él y solo se desbloquea con tu huella, tu cara o tu PIN; la pública se la queda ResidApp y no sirve para entrar a nadie. Al entrar, ResidApp le plantea un reto al dispositivo y este lo firma si tú te verificas. Como la passkey solo responde en la dirección web exacta donde se creó, una página falsa que imite a ResidApp no puede aprovecharla.

Qué necesitas

Con qué cuenta empezar

Con una cuenta que no sea de Plataforma, por ejemplo la de Administración de tu centro. En una cuenta normal la passkey es un camino extra: la contraseña y el código del móvil siguen valiendo, así que equivocarse no deja a nadie fuera. En una cuenta de Plataforma, en cambio, en cuanto hay una passkey la contraseña deja de servir para entrar y la última no se puede quitar: si se pierde el único dispositivo, solo quien administra la base de datos puede borrar la fila y volver a empezar. Por eso, en Plataforma, registra siempre dos passkeys en dos dispositivos distintos.

Paso a paso para añadir una

  1. 1Tú

    Entra con tu contraseña y tu código del móvil, y abre «Mi cuenta» en el menú con tu nombre (arriba a la derecha).

  2. 2Tú

    Baja hasta la ficha «Passkeys» (la de la banda naranja). Si no tienes ninguna, dice «No tienes ninguna passkey».

  3. 3Tú

    Rellena el formulario: un nombre que la reconozca («Windows de Orlando», «Móvil de trabajo»), tu contraseña y el código que da ahora tu móvil. Pulsa «Añadir una passkey».

  4. 4Tu dispositivo

    Se abre una ventana del sistema, no de ResidApp, que te pide el PIN, la huella o la cara. Si ofrece dónde guardarla, elige Windows Hello o «este dispositivo». «Móvil o tableta» muestra un QR para guardarla en el móvil: también vale, pero es más fácil empezar con el propio equipo. ResidApp nunca ve tu PIN ni tu huella.

  5. 5ResidApp

    Te lo confirma en una ventana de aviso («Passkey … añadida») que se cierra con «Entendido», y la nueva aparece en la lista con su fecha y el botón «Quitar».

Cómo comprobar que funciona

Pulsa «Salir» en el menú. En el inicio de sesión pulsa «Entrar con passkey» sin escribir nada: el dispositivo te pide verificarte y entras directamente. Si no tienes a mano el dispositivo donde la registraste, sigues pudiendo entrar con contraseña y código del móvil (salvo en Plataforma).

Qué conviene saber

Cuánto dura la sesión

Cada pantalla que abres y cada dato que guardas cuentan como uso. Leer una pantalla abierta sin tocar nada no cuenta. Un ejemplo inventado, en la Residencia Los Almendros:

  1. 1
    08:00Enfermería

    Entra con almendros-enfermeria, su contraseña y el código del móvil. Se abre su sesión, que durará como mucho hasta las 20:00.

  2. 2
    08:00 – 10:10Enfermería

    Trabaja. Cada pantalla que abre aplaza los 30 minutos de inactividad.

  3. 3
    10:10 – 10:45Enfermería

    Deja la tablet con el basal de Rosa a medias, sin guardar. A las 10:45 pulsa «Guardar»: han pasado 35 minutos sin uso y la app la lleva a la pantalla de acceso, sin más aviso.

    Lo que no había guardado se pierde. Entra otra vez: es una sesión nueva, que durará como mucho hasta las 22:45.

  4. 4
    15:00Auxiliar

    Cambio de turno en la misma tablet. El Auxiliar pulsa «Entrar con otra cuenta» y entra con almendros-auxiliar.

    La sesión de Enfermería se cierra en ese momento: aunque alguien hubiera copiado su cookie, ya no vale.

  5. 5
    22:00Auxiliar

    Pulsa «Salir» al acabar. La sesión queda cerrada y la tablet vuelve al Inicio, sin datos de nadie.

Por qué se cierra una sesión

Qué pasaCuándo se notaQueda registrado como
Pulsas «Salir»En ese momentoSalida (LOGOUT)
Entras con otra cuentaAl entrar con la nuevaCambio de cuenta (CAMBIO_IDENTIDAD)
Cierras otra sesión desde «Mi cuenta», o cambias la contraseñaEn la siguiente pantalla que abra esa sesiónCierre propio (CIERRE_PROPIO)
30 minutos sin usarlaEn la siguiente pantalla que abrasInactividad (INACTIVIDAD)
12 horas desde que entraste, aunque la usesEn la siguiente pantalla que abrasCaducidad (CADUCIDAD)
Administración suspende tu cuentaEn la siguiente pantalla que abrasLa sesión deja de valer y no se puede volver a entrar con esa cuenta.

Las cuentas de prueba: Residencia Los Almendros

Es el centro del Flujo de trabajo y de las guías de pruebas de CJ, ya montado, con una cuenta por perfil. Los pasos 1 a 5 de la vida de Rosa están hechos: el centro con sus dos plantas, sus turnos y sus equipos, Rosa dada de alta en Planta 1 · 104 · B y Elena con acceso al portal. Su historia sigue en vivo desde el paso 6, el basal. Hay además otros cinco residentes para las guías (el Manual dice para qué sirve cada uno). Todos son ficticios.

Cada cuenta se da de alta como en un centro real, con su invitación, su contraseña y su código del móvil. Hay dos juegos con los mismos perfiles, para que nadie comparta contraseñas: el de CJ, que es el de abajo, y el de Orlando, con -orlando en el nombre (por ejemplo, almendros-orlando-enfermeria).

Qué protege y qué no

Trabajar en otro centro con la misma cuenta

Quien ya tiene cuenta en un centro y empieza a trabajar también en otro no necesita otra cuenta. Se hace en tres pasos, sin que la Administración del segundo centro llegue a conocer la cuenta de la persona hasta que ella misma la acepta:

  1. La Administración del centro nuevo prepara una hoja con el perfil (de personal) y las unidades, sin decir a quién, y se la entrega en mano. Lleva un código y un QR, vale 72 horas y se usa una sola vez.
  2. La persona la acepta en «Mi cuenta», ya con su contraseña y su código del móvil: ve el centro, el perfil y las unidades que se le ofrecen y acepta. El segundo factor es lo que demuestra que es quien dice ser; por eso es solo para el personal. Aceptar no concede nada.
  3. La Administración confirma. Ve el nombre y el usuario de quien aceptó y, si es la persona que tenía delante, confirma: entonces se crea el perfil con sus unidades. Si no la reconoce, rechaza y no se concede nada.

Después, al entrar, la persona elige con qué centro trabaja, y cada centro solo ve lo suyo. Como la cuenta es de la persona y no de un centro, ninguna Administración puede suspenderla, cambiarle el nombre ni entregarle una invitación: lo hace la plataforma («Cuentas de varios centros»). Cada Administración puede retirar su propio perfil, y eso no suspende la cuenta. Todo queda en la auditoría del centro y en el registro de accesos de la persona.

Lo que falta: el acceso definitivo

ResidApp tendrá su propio inicio de sesión (con ASP.NET Core Identity, el sistema de cuentas que trae la propia plataforma de la aplicación), con los datos de acceso en la misma base de datos de la UE que el resto. Se hace por partes; las cinco primeras (hasta las passkeys) y la vinculación de cuentas entre centros ya están hechas (ADR 0007), y el acceso de desarrollo se retiró el 24/10/2026.

Antes, alguien tiene que decidir

  • El responsable de protección de datos de la residencia piloto: la evaluación de impacto, qué datos de acceso se guardan y cuánto tiempo, y qué segundo factor acepta para cada grupo de personas.
  • CJ: el segundo factor de los familiares, y si se les puede pedir correo (hoy es opcional en el alta).
  • El tiempo de inactividad definitivo en las tablets compartidas: hoy son 30 minutos y se puede cambiar sin tocar el código.

Para quien mantiene la aplicación

Dónde vive cada pieza. El detalle y las fuentes de la decisión están en docs/decisiones-arquitectura/0007-proveedor-identidad.md.

PiezaDóndeQué hay que saber
Altas de cuentas /Plataforma (Nuevo centro), /Administracion/NuevoUsuario y el acceso al portal en la autorización del familiar El perfil Plataforma no se concede desde Usuarios: su primera cuenta es un INSERT (ADR 0006), y su invitación la emite database/operaciones/invitar_cuenta.sql (emisor ARRANQUE). cuentas.sujeto_externo es único y no se puede modificar (trigger de 0023).
Tiempos de la sesión SessionPolicy (Application) Sesion:InactividadMinutos (30) y Sesion:MaximoHoras (12). La actividad se apunta como mucho una vez por minuto y nunca mueve la caducidad.
Comprobación en cada petición SessionCookieEvents (Web) Cookie residapp_sesion, cifrada con Data Protection, HttpOnly, SameSite=Lax y Secure fuera de Development. Si la sesión no vale, la cierra con su motivo y rechaza la petición.
Sesiones guardadas dbo.sesiones (script 0061), SqlSessionStore Sin seguridad por filas: se lee antes de haber ámbito. No se borra, una sesión cerrada no se reabre y la caducidad no cambia (errores 50535 y 50536). Una sesión abandonada queda abierta en la tabla, pero su siguiente uso la cierra.
Identidad para el resto de la app ISessionIdentityProvider → CookieSessionIdentityProvider Solo da el sujeto de la cuenta. Ámbitos, permisos y la seguridad por filas de SQL siguen igual: cambiar de proveedor en I1 no los toca.
Inicio de sesión con contraseña o passkey AccesoController, SessionSignIn, PendingAccessCookie (Web); SqlCredentialStore (Infrastructure) ASP.NET Core Identity solo para las credenciales (UserManager, sin SignInManager): el usuario es la cuenta y su nombre, sujeto_externo. Contraseña de 12 caracteres o más, bloqueo 5 / 15 min (AccesoOptions), Acceso:IntentosPorMinuto (10). El paso hasta el segundo factor es la cookie residapp_acceso_pendiente (10 min, solo /Acceso, con el sello de seguridad).
Passkeys (I4) PasskeyController, CuentaController (alta y baja), PasskeyStateCookie, PasskeyOrigin, wwwroot/js/passkeys.js (Web); SqlCredentialStore y dbo.passkeys (script 0066) Registrar o usar una passkey son dos pasos seguidos (el servidor pide algo, el dispositivo lo firma y el servidor lo comprueba), y entre un paso y otro el servidor guarda en una cookie (un pequeño fichero que el navegador conserva un rato) el punto en que va. Esa cookie, residapp_passkey, va cifrada para que nadie la altere, dura 5 minutos y vale una sola vez; la del registro, además, queda ligada a la sesión de quien lo pidió. Se usa PasskeyHandler, la pieza de ASP.NET Core Identity que comprueba las passkeys, sin SignInManager, la otra pieza de Identity que gestiona las entradas y que aquí no se usa. El dispositivo siempre pide la huella, la cara o el PIN. La dirección web a la que se ligan las passkeys (el «dominio») se configura en Acceso:PasskeyDominio, una por entorno (en Azure dev, Acceso__PasskeyDominio); si está vacía, las passkeys están desactivadas. Solo se acepta una petición hecha por HTTPS (conexión cifrada) desde ese dominio o desde otro nombre que cuelgue de él.
Credenciales y registro de accesos dbo.credenciales y dbo.eventos_acceso (script 0062), SqlAccessEventLog Sin seguridad por filas. Códigos de recuperación guardados como resúmenes SHA-256; la clave TOTP, en claro, como en el almacén por defecto de Identity. Los intentos fallidos se suman en SQL. eventos_acceso no se modifica ni se borra (errores 50537 y 50538) y nunca guarda lo tecleado.
Invitación de arranque database/operaciones/invitar_cuenta.sql Lo ejecuta a mano quien administra la base, con -v CUENTA=…: emite una invitación (emisor ARRANQUE, script 0067) para cualquier cuenta activa con ámbito e imprime su ruta. Sirve para la primera Plataforma de un entorno y para recuperarla. El acceso de desarrollo (DevAuth) se retiró el 24/10/2026.
Invitaciones dbo.invitaciones_acceso (script 0063), SqlAccessInvitationRepository, AccessInvitationsApplicationService; AccesoController.Invitacion e InvitationCookie Solo se guarda el resumen SHA-256 del token; 72 h; a lo sumo una viva por cuenta (índice único filtrado); se usa una vez (UPDATE condicionado) y no se borra ni se reabre (errores 50539 y 50540). El tipo (alta o recuperación) lo decide si la cuenta ya tiene contraseña. Al abrir el enlace, el token pasa a la cookie residapp_invitacion y se quita de la dirección. Auditoría ACCOUNT_INVITATION_ISSUE, ACCOUNT_RECOVERY_ISSUE y ACCOUNT_INVITATION_CANCEL; registro de accesos INVITACION_USADA, RECUPERACION_USADA e INVITACION_NO_VALIDA; la recuperación cierra las sesiones con el motivo RECUPERACION.
Lo público [AllowAnonymous] en Home, Acceso, Passkey y AccesoCj, y los ficheros estáticos Política global de usuario autenticado. /pendientes-cj va aparte, con su propia clave. Cualquier pantalla pública nueva hay que añadirla a propósito, y SesionTests lo vigila.
HTTPS Program.cs y el CI Cabeceras reenviadas del balanceador de App Service, HSTS y política de cookies. La redirección a HTTPS la hace App Service (httpsOnly, que el CI fija en «Exigir HTTPS en la Web App»).
Cuentas de prueba database/seed/centros_prueba.sql; en la skill probar-en-navegador, alta-juego.js y preparar-almendros.js La semilla crea las cuentas sin contraseña. alta-juego.js da de alta un juego por la cadena real (Plataforma → Administraciones → personal y familia) y guarda sus credenciales fuera del repositorio; preparar-almendros.js deja hecho por la aplicación lo que no se puede sembrar (basales firmados, una foto, un historial).
Pruebas SesionTests, SesionFueraDeDesarrolloTests, SqlSessionStoreTests, SessionPolicyTests, AccesoTests (con AccesoTests.Passkeys.cs y un autenticador de pruebas), SqlCredentialStoreTests Cubren los casos AUTH-SPIKE-T02 a T06: cookie fabricada, sesión cerrada, renovación sin ampliar la caducidad, inactividad y cuenta suspendida. Y de I1: mismo mensaje para todo fallo, bloqueo, segundo factor obligatorio al personal, códigos de recuperación de un solo uso y el paso pendiente que caduca o deja de valer si cambia la contraseña. Y de I4: el alta de una passkey pide contraseña y código, el punto del registro guardado en la cookie vale una sola vez y solo para la sesión que lo pidió, se rechaza una petición hecha desde otra web o con un código de comprobación que no era el pedido, la entrada no abre sesión a una cuenta bloqueada o suspendida y Plataforma con passkey no entra con contraseña. Las demás pruebas funcionales abren sesión con EntradaDePruebas, que solo existe en su servidor de pruebas.