Scripts D2 y QA

Scripts D2 y QA para junior

Esta pagina explica los scripts que se subieron al repo para que cualquier persona pueda correr MedSync local con cookies D2 y comprobar que no regresamos a legacy.

Que significa “script”

Un script es un archivo que automatiza una tarea.

En este proyecto hay dos tipos principales:

• Scripts de arranque local: levantan backend o frontend con la configuracion correcta.
• Scripts QA/security: revisan que algo importante siga funcionando y que no se haya roto por accidente.

No son basura local. Se suben porque otros devs, QA o CI necesitan correrlos igual que nosotros.

Antes de correrlos

Regla simple:

• Si el script solo lee codigo/config, lo puedes correr con confianza.
• Si el script crea fixtures en base de datos, usalo solo en local/dev/staging y con las variables que pide.
• No lo apuntes a produccion.
• No pegues passwords, tokens, cookies completas ni .env.local en chats.

Comando base backend:

cd F:\HemiaAssistantGlobal\hemia-assistance-back-legacy

Comando base frontend:

cd F:\HemiaAssistantGlobal\hemia-assistance-front-legacy

Palabras que vas a ver

Palabra	Significado simple
status	Muestra que revisaria o el estado actual. Normalmente no modifica datos.
validate	Ejecuta la validacion principal.
full	Ejecuta el flujo completo del script. Puede incluir crear y limpiar fixtures.
up	Crea fixtures de QA.
down	Borra fixtures de QA.
hold	Crea fixtures y los deja vivos para probar manualmente. Despues debes correr down.
fixture	Dato falso de prueba, por ejemplo usuario QA, tenant QA o paciente QA.
static source check	Revision de archivos/codigo sin levantar la app ni tocar DB.

Backend

scripts/dev-auth-mode.js

Que hace:

Levanta el backend en modo local D2 o legacy. Es el puente detras de npm run dev, npm run dev:d2 y npm run dev:legacy.

Por que se subio:

Para que npm run dev siempre arranque local con cookies D2 sin que cada dev tenga que recordar todas las variables.

Como se ejecuta:

cd F:\HemiaAssistantGlobal\hemia-assistance-back-legacy
npm run dev

Tambien:

npm run dev:d2

Legacy solo para regresiones:

npm run dev:legacy

Cuando usarlo:

Usalo todos los dias para levantar backend local. No uses dev:legacy salvo que estes comparando comportamiento viejo.

scripts/qa/d2-auth-cookie-config.js

Que hace:

Revisa que la configuracion de cookies D2 sea valida: modo d2, transporte cookie, CSRF activo, CORS con credentials, nombres de cookies y flags como Secure, SameSite y Path.

Por que se subio:

Porque un error de env puede hacer que el navegador vuelva a legacy o que las cookies se creen inseguras.

Como se ejecuta:

node scripts\qa\d2-auth-cookie-config.js validate

Cuando usarlo:

Despues de tocar .env.example, config de cookies, CORS, CSRF o scripts de arranque.

scripts/qa/d2-access-cookie-middleware.js

Que hace:

Comprueba que el middleware de autenticacion pueda leer el access token desde cookie HttpOnly, no solo desde Authorization.

Por que se subio:

D2 necesita que el backend autentique requests del navegador usando cookies.

Como se ejecuta:

node scripts\qa\d2-access-cookie-middleware.js validate

Cuando usarlo:

Despues de tocar Token.Auth, middleware auth, cookies access o validacion de sesiones activas.

scripts/qa/d2-login-set-cookie.js

Que hace:

Revisa que login D2 setee cookies de access/refresh/CSRF y que la respuesta no dependa de tokens visibles para JavaScript.

Por que se subio:

Porque el login es la puerta principal de D2. Si login devuelve tokens o no setea cookies, D2 se rompe.

Como se ejecuta:

node scripts\qa\d2-login-set-cookie.js validate

Cuando usarlo:

Despues de tocar login, controller auth, nombres de cookies o respuesta de login.

scripts/qa/d2-session-endpoint.js

Que hace:

Valida el contrato de /api/auth/session: debe devolver usuario, rol, permisos y tenant sin exponer access token ni refresh token.

Por que se subio:

En D2 el frontend ya no decodifica JWT desde storage; pide la sesion al backend.

Como se ejecuta:

node scripts\qa\d2-session-endpoint.js validate

Cuando usarlo:

Despues de tocar session hydration, DTO de sesion, roles, permisos o tenantOperational.

scripts/qa/d2-refresh-cookie-rotation.js

Que hace:

Revisa que refresh D2 use cookie HttpOnly, rote refresh tokens y no acepte el contrato viejo como flujo normal del navegador.

Por que se subio:

Refresh es sensible: si se rompe, la sesion expira mal; si queda legacy, el refresh token puede volver a JS/body.

Como se ejecuta:

node scripts\qa\d2-refresh-cookie-rotation.js validate

Cuando usarlo:

Despues de tocar refresh token, rotacion, reuse detection o cookies refresh.

scripts/qa/d2-refresh-cookie-runtime-regression.js

Que hace:

Prueba el flujo runtime de refresh cookie-only con mocks: body {}, cookie refresh, rotacion y respuesta sin tokens visibles.

Por que se subio:

Este fue un punto delicado de D2. Sirve para evitar que alguien vuelva a mandar refresh token en body.

Como se ejecuta:

node scripts\qa\d2-refresh-cookie-runtime-regression.js full

Cuando usarlo:

Siempre que toques refresh, payload validation, auth controller, auth DAO o middleware D2.

scripts/qa/d2-logout-clear-cookies.js

Que hace:

Comprueba que logout cierre sesion y limpie cookies con los mismos atributos con los que se crearon.

Por que se subio:

Si logout no limpia bien, el navegador puede quedarse con cookies viejas.

Como se ejecuta:

node scripts\qa\d2-logout-clear-cookies.js validate

Cuando usarlo:

Despues de tocar logout, clear cookie options, path/domain/sameSite o cierre de sesiones.

scripts/qa/d2-csrf-auth-endpoints.js

Que hace:

Valida CSRF en endpoints de auth: login, refresh, logout, forgot/reset y mutaciones protegidas.

Por que se subio:

Con cookies, el navegador manda credenciales automaticamente. CSRF evita que otro sitio dispare acciones por el usuario.

Como se ejecuta:

node scripts\qa\d2-csrf-auth-endpoints.js full

Cuando usarlo:

Despues de tocar csrf.middleware, csrfToken.service, rutas auth o headers X-CSRF-Token.

scripts/qa/d2-csrf-mutating-routes-sweep.js

Que hace:

Hace un barrido de rutas mutantes para detectar endpoints que deberian tener CSRF y no lo tienen.

Por que se subio:

Un endpoint POST, PUT, PATCH o DELETE sin CSRF puede ser una fuga de seguridad en D2.

Como se ejecuta:

node scripts\qa\d2-csrf-mutating-routes-sweep.js validate

Cuando usarlo:

Despues de agregar rutas nuevas o modificar rutas existentes.

scripts/qa/d2-cors-credentialed-allowlist.js

Que hace:

Revisa CORS para cookies: credentials activado, origins exactos, sin wildcard inseguro y headers necesarios como X-CSRF-Token.

Por que se subio:

D2 no funciona bien si CORS no permite credenciales, y es inseguro si permite todo.

Como se ejecuta:

node scripts\qa\d2-cors-credentialed-allowlist.js full

Cuando usarlo:

Despues de tocar CORS, origenes locales/staging, proxy o headers permitidos.

scripts/qa/d2-cookie-auth-integration.js

Que hace:

Prueba integracion D2 con estado falso en memoria: login, session, refresh, logout y compatibilidad legacy aislada.

Por que se subio:

Permite validar el contrato completo sin tocar base de datos real.

Como se ejecuta:

node scripts\qa\d2-cookie-auth-integration.js full

Cuando usarlo:

Despues de cambios grandes en auth D2, antes de pruebas con DB o browser.

scripts/qa/d2-cookie-auth-db-integration.js

Que hace:

Prueba D2 contra base de datos con fixtures ficticios controlados.

Por que se subio:

Algunos errores solo aparecen cuando hay sesiones, refresh tokens y usuarios reales de QA en DB.

Como se ejecuta:

$env:ALLOW_QA_AUTH_FIXTURES='true'
$env:QA_AUTH_PASSWORD='password-qa-no-real'
node scripts\qa\d2-cookie-auth-db-integration.js full

Cuando usarlo:

Solo en local/dev/staging. Usalo cuando necesites validar auth real con DB. No lo apuntes a produccion.

scripts/qa/d2-browser-qa-fixtures.js

Que hace:

Crea usuarios, tenant y datos ficticios para que Playwright o una persona pruebe D2 en navegador.

Por que se subio:

Las pruebas browser necesitan datos falsos repetibles y limpieza segura.

Como se ejecuta:

$env:ALLOW_D2_QA_DB='1'
$env:ALLOW_D2_BROWSER_QA_FIXTURES='1'
$env:QA_AUTH_PASSWORD='password-qa-no-real'
node scripts\qa\d2-browser-qa-fixtures.js full

Para dejar fixtures vivos y probar manualmente:

node scripts\qa\d2-browser-qa-fixtures.js hold

Para limpiar:

node scripts\qa\d2-browser-qa-fixtures.js down

Cuando usarlo:

Cuando vas a correr pruebas browser o necesitas un usuario QA ficticio. Si usas hold, siempre termina con down.

scripts/qa/d2-session-lifecycle-backend.js

Que hace:

Revisa que sesiones, refresh, logout, Super Admin close y reset password invaliden artefactos de auth como se espera.

Por que se subio:

D2 no solo es login. Tambien debe cerrar sesiones y cortar refresh tokens cuando corresponde.

Como se ejecuta:

node scripts\qa\d2-session-lifecycle-backend.js full

Cuando usarlo:

Despues de tocar lifecycle de sesion, reset password, Super Admin close, session DAO o refresh tokens.

scripts/qa/auth-password-reset-fixtures.js

Que hace:

Crea y valida fixtures ficticios para forgot/reset password.

Por que se subio:

Reset password debe invalidar sesiones y no filtrar OTP/passwords.

Como se ejecuta:

$env:ALLOW_QA_AUTH_FIXTURES='true'
$env:QA_AUTH_PASSWORD='password-qa-no-real'
node scripts\qa\auth-password-reset-fixtures.js full

Cuando usarlo:

Cuando trabajes forgot password, OTP, reset password o invalidacion de sesiones despues de cambiar password.

scripts/qa/auth-refresh-token-fixtures.js

Que hace:

Crea y valida fixtures para refresh token v2: hash, rotacion, revocacion y reuse detection.

Por que se subio:

El refresh token es una pieza critica de seguridad y no debe volver a guardarse en frontend.

Como se ejecuta:

$env:ALLOW_QA_AUTH_FIXTURES='true'
$env:QA_AUTH_PASSWORD='password-qa-no-real'
node scripts\qa\auth-refresh-token-fixtures.js full

Cuando usarlo:

Despues de tocar refresh tokens, sesiones, logout, reset password o reuse detection.

scripts/qa/auth-final-regression.js

Que hace:

Corre una regresion grande de auth/login/forgot password con fixtures controlados.

Por que se subio:

Sirve como prueba macro antes de cerrar una fase de auth.

Como se ejecuta:

$env:ALLOW_QA_AUTH_FIXTURES='true'
$env:QA_AUTH_PASSWORD='password-qa-no-real'
node scripts\qa\auth-final-regression.js full

Cuando usarlo:

Antes de entregar cambios grandes de auth o antes de una validacion externa.

scripts/qa/authz-fase0-regression.js

Que hace:

Valida permisos backend de Fase 0: roles, rutas clinicas, PHI, tenant, super_admin bloqueado en rutas clinicas y permisos legacy.

Por que se subio:

Esto protege contra regresiones de autorizacion, no solo autenticacion.

Como se ejecuta:

npm run qa:authz-fase0

Equivalente:

node scripts\qa\authz-fase0-regression.js

Cuando usarlo:

Despues de tocar permisos, roles, guards backend, rutas clinicas o legacy routes.

scripts/qa/security-multitenant-idor-suite.js

Que hace:

Crea tenant A y tenant B ficticios, intenta cruzar IDs entre tenants y espera 403/404 sin fuga de datos.

Por que se subio:

MedSync es multi-tenant y maneja PHI. IDOR multi-tenant es riesgo critico.

Como se ejecuta:

npm run qa:security-idor -- full

Cuando usarlo:

Despues de tocar endpoints de pacientes, citas, historias, recetas, documentos, archivos, configuracion clinica o cualquier filtro por tenant.

scripts/qa/security-auth-cookies-whitebox-audit.js

Que hace:

Audita codigo/config de auth cookies: HttpOnly, CSRF, CORS, ausencia de tokens en frontend y piezas relacionadas.

Por que se subio:

Es una revision de seguridad rapida para detectar regresiones antes de browser QA.

Como se ejecuta:

npm run qa:security-auth-cookies

Cuando usarlo:

Despues de tocar auth cookies, CSRF, CORS, frontend auth o storage.

scripts/qa/security-headers-http-regression.js

Que hace:

Levanta o consulta HTTP real para validar headers de seguridad: Helmet/equivalente, CSP report-only, frame protections, HSTS cuando aplica y Permissions-Policy.

Por que se subio:

Los headers se validan mejor con una respuesta HTTP real, no solo leyendo codigo.

Como se ejecuta:

npm run qa:security-headers

Cuando usarlo:

Despues de tocar Helmet, CSP, headers, middleware de seguridad o configuracion de ambiente.

scripts/qa/remote-signing-fixtures.js

Que hace:

Crea y valida fixtures de firma documental remota: solicitudes, permisos, eventos/logs y validaciones multi-tenant.

Por que se subio:

Documentos y firma tienen superficie sensible; necesitan fixtures controlados para pruebas reales.

Como se ejecuta:

node scripts\qa\remote-signing-fixtures.js status

Para crear/validar/limpiar en ambiente seguro:

node scripts\qa\remote-signing-fixtures.js up
node scripts\qa\remote-signing-fixtures.js validate
node scripts\qa\remote-signing-fixtures.js down

Cuando usarlo:

Cuando trabajes documentos/firma remota. Lee su salida help antes de usar modos que escriben datos.

Frontend

scripts/dev-auth-mode.js

Que hace:

Levanta el frontend en D2 o legacy. Es el script detras de npm run serve, npm run serve:d2, npm run serve:legacy, serve:lan y serve:lan:legacy.

Por que se subio:

Para que el frontend local arranque con cookies D2 sin que el dev recuerde variables VUE_APP_*.

Como se ejecuta:

cd F:\HemiaAssistantGlobal\hemia-assistance-front-legacy
npm run serve

Tambien:

npm run serve:d2

Legacy solo para regresiones:

npm run serve:legacy

Cuando usarlo:

Todos los dias para levantar frontend local. No uses legacy salvo que estes comparando el comportamiento viejo.

scripts/qa/d2-auth-client-foundation.js

Que hace:

Revisa la base del cliente D2: withCredentials, CSRF, sin Authorization y clientes de session/auth.

Por que se subio:

Es la primera barrera para evitar que el frontend vuelva a mandar tokens por header.

Como se ejecuta:

node scripts/qa/d2-auth-client-foundation.js full

Cuando usarlo:

Despues de tocar axios, auth service, CSRF service o config de transporte.

scripts/qa/d2-store-token-removal.js

Que hace:

Revisa que Vuex/store no persista access token, refresh token, permisos, business ni tenantOperational como secretos largos.

Por que se subio:

D2 busca que access/refresh no vivan en JavaScript ni storage.

Como se ejecuta:

node scripts/qa/d2-store-token-removal.js full

Cuando usarlo:

Despues de tocar store auth, Vuex, session cleanup o persistencia local.

scripts/qa/d2-router-session-hydration.js

Que hace:

Revisa que router use /api/auth/session y estado runtime, no JWT decodificado desde storage.

Por que se subio:

En D2 el usuario/permisos vienen del backend, no de un token visible en frontend.

Como se ejecuta:

node scripts/qa/d2-router-session-hydration.js full

Cuando usarlo:

Despues de tocar router, guards, rutas protegidas o redirecciones por rol/tenant.

scripts/qa/d2-logout-401-cleanup.js

Que hace:

Revisa que logout y respuestas 401 limpien runtime, CSRF y residuos legacy sin borrar el identificador recordado permitido.

Por que se subio:

Cuando una sesion expira o se cierra por seguridad, el frontend debe quedar limpio.

Como se ejecuta:

node scripts/qa/d2-logout-401-cleanup.js full

Cuando usarlo:

Despues de tocar logout, interceptores 401, cleanup helpers o login/session state.

scripts/qa/d2-core-layouts-auth-views.js

Que hace:

Revisa layouts principales y vistas auth para confirmar que usan D2 runtime y no leen tokens/refreshtokens desde JS.

Por que se subio:

Muchas regresiones nacen en vistas o layouts que leen $session viejo.

Como se ejecuta:

node scripts/qa/d2-core-layouts-auth-views.js full

Cuando usarlo:

Despues de tocar login, layout principal, vistas auth o componentes base.

scripts/qa/d2-clinical-patient-views.js

Que hace:

Revisa vistas clinicas/paciente para que no construyan Authorization manual ni pasen tokens manuales a servicios.

Por que se subio:

Las rutas clinicas manejan PHI; no deben volver a depender de tokens visibles.

Como se ejecuta:

node scripts/qa/d2-clinical-patient-views.js full

Cuando usarlo:

Despues de tocar pacientes, historia clinica, documentos, recetas, odontograma, citas o servicios clinicos.

scripts/qa/d2-session-lifecycle-frontend.js

Que hace:

Revisa lifecycle frontend: reload, nueva pestana, refresh, logout, 401, Super Admin close y limpieza local.

Por que se subio:

D2 debe funcionar aunque el usuario recargue, abra pestanas o su sesion sea cerrada por seguridad.

Como se ejecuta:

node scripts/qa/d2-session-lifecycle-frontend.js full

Cuando usarlo:

Despues de tocar session service, router guards, interceptores, logout o cleanup.

scripts/qa/d2-frontend-regression.js

Que hace:

Ejecuta una regresion estatica amplia que agrupa las revisiones D2 principales del frontend.

Por que se subio:

Es el comando rapido para verificar que el frontend sigue alineado con D2.

Como se ejecuta:

node scripts/qa/d2-frontend-regression.js full

Cuando usarlo:

Antes de entregar cambios de frontend relacionados con auth, router, store, layouts o vistas clinicas.

scripts/qa/d2-browser-security-evidence.js

Que hace:

Usa Playwright/browser real para comprobar cookies, storage, document.cookie, Network sin Authorization, CSRF y logout.

Por que se subio:

La prueba final de D2 debe observar el navegador real, no solo el codigo.

Como se ejecuta:

node scripts/qa/d2-browser-security-evidence.js

Normalmente requiere backend/frontend levantados y fixtures ficticios ya preparados en backend.

Cuando usarlo:

Despues de levantar local D2 completo o antes de cerrar una fase de seguridad.

scripts/qa/enforce-https-api-url.js

Que hace:

Bloquea builds productivos/staging si VUE_APP_CORE_URL_API usa http://.

Por que se subio:

Produccion/staging deben apuntar a API HTTPS. HTTP productivo rompe el objetivo de cookies seguras.

Como se ejecuta:

node scripts/qa/enforce-https-api-url.js production
node scripts/qa/enforce-https-api-url.js staging

Tambien corre automaticamente en:

npm run build
npm run build-stage

Cuando usarlo:

Despues de tocar .env.production, .env.staging, deploy frontend o configuracion de API URL.

Que correr en el dia a dia

Si solo quieres levantar local:

# Backend
cd F:\HemiaAssistantGlobal\hemia-assistance-back-legacy
npm run dev

# Frontend
cd F:\HemiaAssistantGlobal\hemia-assistance-front-legacy
npm run serve

Si cambiaste auth/cookies en backend:

cd F:\HemiaAssistantGlobal\hemia-assistance-back-legacy
node scripts\qa\d2-auth-cookie-config.js validate
node scripts\qa\d2-refresh-cookie-runtime-regression.js full
npm run qa:security-auth-cookies

Si cambiaste auth/frontend:

cd F:\HemiaAssistantGlobal\hemia-assistance-front-legacy
node scripts/qa/d2-frontend-regression.js full
node scripts/qa/d2-session-lifecycle-frontend.js full

Si cambiaste permisos o tenant backend:

cd F:\HemiaAssistantGlobal\hemia-assistance-back-legacy
npm run qa:authz-fase0
npm run qa:security-idor -- full

Si cambiaste headers:

cd F:\HemiaAssistantGlobal\hemia-assistance-back-legacy
npm run qa:security-headers

Que NO subir como si fueran scripts QA

No subas por accidente:

• .env
• .env.local
• passwords;
• tokens;
• cookies completas;
• logs con datos sensibles;
• archivos de src/tempFolder;
• capturas o descargas temporales;
• migraciones SQL si no pertenecen al cambio que vas a commitear.

Los scripts QA se suben porque son parte del seguro del proyecto. Los temporales no.