Comentarios: git diff origin/develop -- actions/authentication.test.js

Contraseña incorrecta (401):

• mockResolvedValue (sin Once) — todas las llamadas devuelven 401. loadUserStatus() no se llama (el login falló antes).
• error: 'Fetch failed: Error 401' correcto — entonces handleHTTPErrors lanza Error('Fetch failed: Error ${status}').
• La prueba antigua esperaba 'Unauthorized' — incorrecto.

Fallo de red — PRUEBA NUEVA (no existía en el archivo antiguo):

mockRejectedValue(new Error('Network error')) — [documentación vitest]. Simula un error de red/DNS. fetch no devuelve respuesta, en su lugar lanza una excepción. login() → fetch(...) → red caida → .catch(catchError(dispatch)) → dispatch(USER_LOGIN_FAILURE('Network error')). [authentication.js:84]

Eliminado por completo (2 pruebas, ~30 líneas).

Razones:

1. userLogout() devuelve { type: USER_LOGOUT } — trivial, mismo nivel que creador de acciones. USER_LOGOUT no se exporta desde authentication.js [solo 3 tipos].
2. logout() despacha una sola acción — sin código asíncrono.
3. Ambas dependen de cookies.loadAll() (react-cookies), que se eliminó.
4. La funcionalidad de cierre de sesión está cubierta por USER_LOGIN_BEGIN (reinicialización del estado).

TODO clave: 7 años.

// TODO: ADD AUTHENTICATION TEST ENDPOINT [línea 211] — añadido el 17-03-2019, permaneció así 7 años hasta que el PR 7e78f3741 lo resolvió. La prueba antigua loadSessionIfAvailable solo devolvía estado 200, sin cuerpo JSON. response.json() habría fallado. La prueba nunca se ejecutó.

'creates no action at all' eliminado — verificaba que loadSessionIfAvailable() devolvía null sin simulación. En el código actual loadUserStatus() siempre realiza un fetch.

Respuesta JSON correcta: json: () => Promise.resolve({ userData, systemData, alertMessage }) — la estructura coincide con lo que loadUserStatus() espera en authentication.js:42.

alertMessage: 'Some alert' — verifica la propagación del mensaje de alerta (era undefined en la prueba de login — diferentes caminos de código).

Prueba nueva — no existía en el archivo antiguo.

payload: { error: undefined } — peculiaridad de loadUserStatus(): en el manejador catch se llama catchError(dispatch)({ message: undefined }). catchError = (dispatch) => (error) => dispatch(userLoginFailure(error.message)) — error.message es undefined porque se pasa el objeto { message: undefined }.

Verificación vía actions[0] y actions[1] (no toEqual de todo el array) — porque loadUserStatus() en error ejecuta window.location.href = (redirección a /login), lo cual puede no funcionar en jsdom.

Thunk de Redux

Middleware que permite despachar funciones (no solo objetos). La función recibe (dispatch, getState) — puede realizar fetch y despachar múltiples acciones. login() y loadUserStatus() son thunks: devuelven function(dispatch) { ... }. Sin el middleware redux-thunk, Redux los rechazaría. [documentación]

Creador de acciones vs Thunk

Un creador de acciones (userLoginBegin()) devuelve un objeto { type, payload } — se despacha síncronamente. Un thunk (login(username, password)) devuelve una función — el middleware la ejecuta asíncronamente, realiza fetch y despacha múltiples acciones. Dos capas diferentes: creadores = fábrica síncrona de objetos, thunks = orquestador asíncrono.

JSESSIONID

Cookie de sesión estándar de Java. No creada por el código de ProjectForge — la establece el contenedor de servlets (Tomcat/Jetty) en la primera request.getSession(true). ProjectForge gestiona su ciclo de vida:

• Después del login — invalidación y recreación (protección contra fijación de sesión): LoginService.kt:333-342

  // Fijación de Sesión: Cambiar JSESSIONID después del login
  request.getSession(false)?.let { session ->
      if (!session.isNew) { session.invalidate() }
  }
  val session = request.getSession(true)  // ← nueva JSESSIONID
  session.setAttribute(SESSION_KEY_USER, userContext)

• Envío de vuelta — cada fetch() envía la cookie vía credentials: 'include' en authentication.js:37:

  fetch(getServiceURL('userStatus'), {
      method: 'GET',
      credentials: 'include',  // ← envía JSESSIONID al servidor
  })

Cuando expira — la sesión muere, GET /rs/userStatus devuelve 401. La cookie es HTTP-only: JavaScript no puede leerla vía document.cookie. [Wikipedia: Session ID]

KEEP_SIGNED_IN / stayLoggedIn

Casilla de verificación "mantener sesión iniciada" en el formulario de login. Frontend: parámetro keepSignedIn en authentication.js:65 → se envía como { stayLoggedIn: true } en el cuerpo POST (línea 77). El servidor genera el token STAY_LOGGED_IN_KEY y establece una cookie llamada "stayLoggedIn" (CookieService.kt:201). KEEP_SIGNED_IN — nombre antiguo del lado del cliente, eliminado en Mar 2019. La prueba antigua usaba exactamente ese (cookies.save('KEEP_SIGNED_IN', ...)) — nombre incorrecto + fetch-mock no establece cookies = la prueba verificaba vacío.

Cookie HTTP-only

Cookie con la bandera HttpOnly. El navegador la envía al servidor, pero JavaScript no tiene acceso — document.cookie no la incluye. JSESSIONID es HTTP-only (protección contra XSS). Por eso cookies.loadAll() (que lee document.cookie) nunca ve la cookie de sesión. [MDN]

vi.fn()

Constructor de función simulada de Vitest. Equivalente a jest.fn(). mockResolvedValueOnce(x) — la próxima llamada devuelve Promise.resolve(x) (cadena). mockResolvedValue(x) — todas las llamadas devuelven Promise.resolve(x). mockRejectedValue(e) — la llamada lanza un error (fallo de red). La distinción Once / no-Once es crítica: en la prueba de login, dos llamadas fetch se simulan secuencialmente. [vitest]

import.meta.env.DEV / MODE

Reemplazo de Vite para process.env.NODE_ENV. import.meta.env.DEV — true en modo desarrollo. import.meta.env.MODE — string: 'development', 'production' o 'test'. Reemplazo necesario porque process.env.NODE_ENV de CRA no existe en Vite. En rest.js:10: DEV && MODE !== 'test' — servidor de desarrollo, pero no el runner de pruebas. [documentación vite]

connect() → useSelector/useDispatch

Dos formas de conectar componentes React con la tienda Redux. connect(mapStateToProps)(Component) — patrón HOC (pre-2019), envuelve el componente. useSelector(state => state.user) + useDispatch() — hooks (React 16.8+), más simples, amigables con TypeScript, optimizables por tree-shaking. loggedIn: boolean cambió a user: object|null precisamente por el cambio a hooks: el selector state => state.authentication.user !== null lee un campo específico en lugar de una bandera. [react-redux]

loadUserStatus()

Thunk llamado al inicio de la aplicación y después del login. Realiza GET /rs/userStatus con cookie (credentials: 'include'). El servidor verifica la sesión: si es válida — devuelve { userData, systemData, alertMessage } (200). Si expiró — 401 → redirección a /react/public/login. Esto es lo primero que hace React al cargar (ver ProjectForge.jsx): "¿quién soy?". [authentication.js:30]