ResidApp · Acceso y sesión
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.
Al personal y a las familias, la Administración de su centro. A la primera Administración de un centro nuevo, Plataforma. «Cómo pedir el acceso», en la pantalla de acceso, lo explica.
Tu identificador de acceso y tu contraseña; el personal, además, el código de 6 cifras
de su aplicación de autenticación; o, si has registrado una, «Entrar con passkey». La primera vez, la
invitación de tu Administración. En el entorno de pruebas, igual, con las cuentas de prueba (por ejemplo,
almendros-enfermeria).
Si tu cuenta tiene más de un perfil o más de un centro, eliges con cuál trabajas. Lo que ves y lo que puedes hacer depende de esa elección.
La sesión se cierra tras 30 minutos sin usarla y, en todo caso, a las 12 horas de entrar. Guarda lo que estés escribiendo antes de dejar la tablet.
En una tablet compartida, pulsa siempre «Salir». Cerrar el navegador no siempre basta: algunos recuperan la sesión al volver a abrirse.
El Inicio, el Manual, el Flujo de trabajo, esta página y la página sin conexión. Todo lo demás te lleva a la pantalla de acceso.
Solo abre /pendientes-cj, no la aplicación. Para la aplicación, cada persona usa su propia cuenta.
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.
| Si eres… | Lo pides a… | Qué hace quien te lo da | Con 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 |
Así recibe cada persona su contraseña (ADR 0007, hecho el 22/10/2026):
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.
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.
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.
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.
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.
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.
Desde ahí, la Administración monta el centro y da el resto de accesos.
Es la forma de recuperar una unidad que se quedó sin nadie que la gestione.
Soporte no crea ni reactiva cuentas de personal desde la aplicación.
database/operaciones/invitar_cuenta.sql
y se la entrega en privado.La aplicación todavía no permite a Plataforma reactivar una cuenta ni crear otra Administración en un centro que ya existe. Lo resuelve por SQL quien administra la base de datos.
Solo por SQL, quien administra la base de datos (ADR 0006). Nunca desde la aplicación. Lo mismo si pierde todas sus passkeys:
se borran sus filas de la tabla passkeys y vuelve a entrar con su contraseña y su código del móvil para registrar otra.
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.
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.
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.
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.
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.
app-residapp-dev.azurewebsites.net.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.
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).
Baja hasta la ficha «Passkeys» (la de la banda naranja). Si no tienes ninguna, dice «No tienes ninguna passkey».
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».
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.
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».
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).
Una invitación de recuperación, además de la contraseña y el código del móvil, borra todas tus passkeys: hay que añadirlas de nuevo.
Cada una con su nombre, para saber cuál es de cada dispositivo. Una cuenta de Plataforma no puede quitar la última.
No se pueden mover a otra: si la dirección de ResidApp cambiara, habría que registrarlas de nuevo.
Si tu móvil o tu portátil las sincroniza con tu cuenta de Google o de Apple, «Mi cuenta» lo indica en esa passkey.
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:
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.
Trabaja. Cada pantalla que abre aplaza los 30 minutos de inactividad.
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.
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.
Pulsa «Salir» al acabar. La sesión queda cerrada y la tablet vuelve al Inicio, sin datos de nadie.
| Qué pasa | Cuándo se nota | Queda registrado como |
|---|---|---|
| Pulsas «Salir» | En ese momento | Salida (LOGOUT) |
| Entras con otra cuenta | Al entrar con la nueva | Cambio de cuenta (CAMBIO_IDENTIDAD) |
| Cierras otra sesión desde «Mi cuenta», o cambias la contraseña | En la siguiente pantalla que abra esa sesión | Cierre propio (CIERRE_PROPIO) |
| 30 minutos sin usarla | En la siguiente pantalla que abras | Inactividad (INACTIVIDAD) |
| 12 horas desde que entraste, aunque la uses | En la siguiente pantalla que abras | Caducidad (CADUCIDAD) |
| Administración suspende tu cuenta | En la siguiente pantalla que abras | La sesión deja de valer y no se puede volver a entrar con esa cuenta. |
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).
almendros-administracion
Administración principal de las dos plantas: residentes, familias, usuarios, estructura, turnos, citas y auditoría.
No ve nada clínico.
almendros-direccion
Las dos plantas. Puede leer lo clínico declarando para qué (queda auditado), fijar los rangos de referencia y los plazos de los hitos.
La lectura declarada termina al salir o al entrar con otra cuenta.
almendros-medicina
Las dos plantas, con permiso para firmar y reevaluar el basal.
almendros-enfermeria
Las dos plantas, con permiso de basal, y en el equipo de Enfermería de cada planta. Empieza por firmar el basal de Rosa.
almendros-auxiliar
Solo Planta 1. Tiene a cinco residentes en «Mis residentes», entre ellos Rosa.
No ve la Planta 2.
almendros-elena
Elena, hija de Rosa y su contacto prioritario, con la autorización activa. Entra directamente en el Portal Familiar.
plataforma-cj
No es del centro: es global. Da de alta centros nuevos y atiende a sus Administraciones.
Nunca ve residentes.
olmos-administracion y
olmos-enfermeria), sirve para comprobar que cada centro solo ve lo suyo.varios-centros, que tiene perfiles en los dos centros. El
resto está en el Manual.La sesión viaja en una cookie que el servidor cifra y firma. La cookie antigua, con el usuario escrito tal cual, ya no da acceso: era el fallo más grave del entorno publicado y está cerrado.
Cada sesión es una fila en la base de datos y se comprueba en cada pantalla. Al salir, una copia de la cookie deja de valer al instante.
Inactividad, caducidad o cuenta suspendida llevan a la pantalla de acceso. Seguir usando la sesión nunca alarga las 12 horas.
Una dirección http:// pasa a https:// y el navegador recuerda no volver a usar http.
Las cookies solo viajan cifradas y las páginas no pueden leerlas.
El acceso de desarrollo (entrar escribiendo solo el nombre de una cuenta) se retiró el 24/10/2026, también del entorno de pruebas. Las pruebas automáticas usan una entrada que solo existe dentro de ellas y nunca se publica.
Toda pantalla exige sesión salvo una lista cerrada. Una prueba automática recorre las más de 150 acciones de la aplicación y falla si alguna queda abierta sin querer.
La contraseña se guarda como un resumen que no se puede revertir; el personal necesita además el código de su móvil, o entra con una passkey: la clave que te desbloquea y prueba que eres tú no sale nunca de tu dispositivo, y ResidApp guarda solo la que sirve para comprobarla, que por sí sola no permite entrar. Cinco fallos bloquean la cuenta y todo queda en un registro de accesos separado de la auditoría clínica.
La pulsera con PIN para las tablets compartidas (I5) aún no existe, y falta la validación del responsable de protección de datos (DPO) de la residencia piloto. Hasta entonces solo se usan datos ficticios.
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:
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.
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.
Dónde vive cada pieza. El detalle y las fuentes de la decisión están en
docs/decisiones-arquitectura/0007-proveedor-identidad.md.
| Pieza | Dónde | Qué 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. |