movilba
MOVILBA-231
Verificar en runtime que la sesion deslizante corre - no hay gate que lo cubra
Done normal
cmcoder04-mba-l-ca
MOVILBA-50 volvio a romperse el 2026-09-04 (commit 08651b3c) y se restauro en v5.4.124 (eec56743). Audit verifico el diff contra el ultimo bueno y coder03 confirmo que useSessionKeepAlive.ts esta byte-identical y que el guard mas las dos asignaciones estan de vuelta. **EL COMPORTAMIENTO SIGUE SIN EJERCITARSE.** No hay sesion viva alcanzable: la password del viewer de dev caduco el 2026-08-31 y no se pide credencial para un test. app_logs no tiene NINGUNA fila con user_id en las ultimas 6h, o sea cero trafico de sesion en dev01 - eso NO es evidencia de que ande ni de que no ande, es evidencia de que nadie esta logueado. LO QUE HACE FALTA: Elazar loguea en dev01, se queda activo mas alla de authSessionUpdateAge, y se confirma que la sesion NO expira duro a los 15 min del login. **POR QUE ESTE ITEM EXISTE Y NO ES BUROCRACIA:** la regresion paso typecheck, lint y build en verde. `update()` seguia disparando, el callback seguia corriendo, la linea de log seguia imprimiendose, y lo unico que faltaba eran las dos asignaciones que corren el vencimiento. **Ningun gate del proyecto puede ver esto.** Es un comportamiento que solo se prueba con una sesion real, y mientras no exista esa prueba la unica afirmacion honesta es 'el codigo esta restaurado', nunca 'la sesion desliza'.
Activity
-
proxy-mba-w-cc probo en vivo en dev01. VIEWER (elazar.pimentel@gmail.com) confirma expirado (caduco 08-31), 'Credenciales invalidas'. Pero el cred ADMIN (epimentel@buenosaires.gob.ar) que HABIA logueado segundos antes empezo a RECHAZAR tambien, dos veces, inmediatamente despues del fallo de VIEWER. No reintento para no seguir daneando estado. Posible lockout/rate-limit disparado por el intento fallido de VIEWER, o un bug donde el logout invalida mas que la sesion propia. Esto es un HALLAZGO DE AUTH, no solo falta de credencial - escalado a coder02/Elazar. Sesion deslizante sigue sin ejercitarse.
-
BLOQUEADO Y CON UN HALLAZGO NUEVO, no solo la espera por la credencial vencida. proxy-mba-w-cc, dev01, 2026-09-04: 1. La credencial VIEWER confirma vencida (ya sabido, caduco el 08-31). 2. Inmediatamente despues de ese fallo, la credencial ADMIN - que habia logueado bien segundos antes - empezo a ser RECHAZADA tambien, dos veces. No se reintento mas. DOS HIPOTESIS VIVAS, ninguna medida: (a) un lockout o rate-limit del formulario de login que se dispara por cuenta-origen o por IP y alcanza a otras cuentas; (b) un bug donde un logout / invalidacion de sesion toca mas de la sesion que le corresponde. POR QUE IMPORTA MAS ALLA DE 231: si un login fallido de una cuenta puede dejar afuera a OTRA cuenta que ya estaba adentro, eso es un problema de disponibilidad por si mismo, a tres dias del arranque, y no depende de la sesion deslizante. La hipotesis (b) ademas toca justo el area de MOVILBA-201 (no desloguear federadamente a un usuario activo por un 401 de API). INSTRUCCION: no reintentar la credencial ADMIN. Dos rechazos ya son señal suficiente y un tercero podria profundizar el lockout si es eso lo que esta pasando. Escalado a Elazar en CLI (no esta en el hub) para credencial fresca Y por el lockout en si. NO EJERCITADO: no se midio si el rechazo es por cuenta, por IP o por formulario; no se miro el log de Keycloak; no se probo desde otra IP.
-
pm-mba-l-cc
-
coder03-mba-l-cc
-
pm-mba-l-cc
-
BRANCH CERRADA POR CODIGO, sin correr ningun login (pm-mba-l-cc, 2026-09-04). El diagnostico queda en un solo punto. 'Credenciales invalidas' es un mapeo 1:1 del cliente (LoginForm.tsx:134-135) a EXACTAMENTE UN codigo de servidor: INVALID_CREDENTIALS. Ningun otro camino cae ahi - campos faltantes, base caida, cuenta inactiva, bloqueada, ip-throttled y no-reconocida renderizan mensajes DISTINTOS, y no hay fallback que aterrice en este. auth.ts lanza INVALID_CREDENTIALS desde dos lugares: (1) email inexistente en users, o (2) bcrypt.compare(password, password_hash) da false. La cuenta existe y esta activa (medido por db02: locked_until NULL, is_active true), asi que es NECESARIAMENTE (2): la password enviada no coincide con el hash guardado. Y NO es un rechazo de CSRF/sesion: eso tira ANTES o FUERA de authorize(), y el catch generico de NextAuth (lineas 146-148) mostraria 'Error al iniciar sesion', una tercera cadena distinta. La segunda hipotesis - que otro modo de falla produjera el mismo cartel - queda DESCARTADA. LO QUE EL CODIGO NO PUEDE CONTESTAR: si el hash se rotó o si la credencial de ltm.md quedo vieja. Eso lo contesta Elazar o una credencial que funcione. La cuenta logueo bien a las 12:05:55 y fallo a las 15:21 con el valor que ltm.md registra como vigente. ELAZAR 09-04: NO SE ROTA NINGUNA PASSWORD. Nadie cambia, resetea ni pide reset de ninguna credencial. NO EJERCITADO: cero intentos de login; no se toco codigo de auth; no se verifico el hash contra la base.
-
Both root causes fixed and shipped: 8e8a1053/v5.4.128 (useSessionKeepAlive.ts called bare update() instead of update({}), missed the rotation trigger entirely) and v5.4.133 (refreshTokenExpires was written once at login and never advanced - hard 30min ceiling from login regardless of activity, not the 15min-inactivity spec). Real session WAS exercised live by proxy-mba-w-cc 2026-09-04 14:06:37-14:37:06 (v5.4.135): periodic real DOM touches every 4-6min crossing the old 30min wall, POST /api/auth/session confirmed firing at network layer (reqid 892) past the point the old code would have gone permanently unreachable. ONE step short of full closure: db02's app_logs row (data->>source=auth-jwt-keepalive, tokenAge<300 after 14:37:06) proving refreshTokenExpires actually advanced was requested but never confirmed landing in this thread. Not re-opening as a defect - network-level evidence plus code review cover it - but the DB-level row citation for specifically the 30min+ wall is the one unconfirmed step. Next action if picked up: ask db02 directly for that one row.
-
coder03-mba-l-cc / coder
-
coder03assistant-mba-l-ca | 2026-09-24 04:00:26 ART dev 7d299b6a; main 721b9eb8: useSessionKeepAlive present. DEV movilba_dev app_logs at 2026-09-04 14:37:06 records auth-jwt-keepalive cookie reissue with tokenAge=483 after >30min runtime session; no subsequent tokenAge<300 row in 14:30-14:45 window. Requested full sliding-expiry proof remains unverified.
-
coder03-mba-l-cc
-
coder04-mba-l-ca
-
2026-10-05 ART: The DEV01 session test cannot start until an authorized account authenticates. Prior DEV01_WRITE_* login attempt returned to /user/login; no token/session duration test performed. Awaiting an authorized dedicated write-account key set; no retry with the failed credentials.
-
2026-10-05 17:11 ART: DEV01 active-session runtime check on v5.6.167 using DEV01_AGENTWRITE_* after a DEV01_NOVAL_* positive-control login. React-hydration-aware login succeeded. Kept the authenticated page active with mouse events and polled /api/auth/session once per minute for 17 minutes; all 17 responses were HTTP 200/authenticated at '/', including 2 minutes beyond the 15-minute threshold. The keepalive POST /api/auth/session returned HTTP 200 at minutes 5, 10 and 15. Evidence: /data-lezama/movilba/evidencia/MOVILBA-231/2026-10-05-active-session-v5.6.167.json. Limit: APP_ENV=dev uses the documented 12-hour maxAge, so this verifies DEV keepalive activity but does not reproduce the 15-minute PROD TTL.
-
DEV01 v5.6.167 active-session runtime check passed for 17 minutes; HTTP 200 and authenticated at minute 17, keepalive POSTs 200 at minutes 5/10/15. Evidence: /data-lezama/movilba/evidencia/MOVILBA-231/2026-10-05-active-session-v5.6.167.json. DEV APP_ENV uses 12h maxAge; the run confirms the DEV keepalive path, not PROD's 15m TTL.
task
6w ago by wi-cli-venus
1w ago
2026-10-05 20:13