D2 Production Para Juniors

D2 production-like para juniors

Esta pagina explica el camino desde local D2 hasta un ambiente production-like o produccion.

No activa produccion. No marca MedSync como production-ready. Sirve para entender que piezas deben existir antes de pedir go/no-go.

Que significa esto en palabras simples

En local usamos HTTP. Por eso las cookies locales se llaman:

medsync_at_dev
medsync_rt_dev
medsync_csrf_dev

Y en local HTTP se permite:

Secure=false

Eso solo es aceptable en local.

En staging, production-like o produccion debe existir HTTPS real. Cuando hay HTTPS, las cookies auth deben ir con:

Secure=true

La idea production-like ideal es:

__Host-medsync_at
__Host-medsync_rt
__Host-medsync_csrf

Diferencia local vs produccion

Local:
http://localhost:8080
http://127.0.0.1:3009
cookies: medsync_at_dev

Produccion:
https://app.midominio.com
https://api.midominio.com
cookies: __Host-medsync_at

Local sirve para desarrollar rapido. Production-like sirve para probar como se comportara el navegador real con TLS, dominios, CORS, CSRF, cookies Secure, reset password, logs, backups y rollback.

Que significa `__Host-*`

__Host-* es un prefijo especial para cookies. El navegador exige reglas mas estrictas.

Para usar __Host-medsync_at, __Host-medsync_rt o __Host-medsync_csrf:

debe ser HTTPS;
la cookie debe tener Secure=true;
la cookie debe tener Path=/;
la cookie no debe tener Domain.

Si falta una de esas reglas, el navegador puede rechazar la cookie.

Variables que debes esperar en backend

Ejemplo production-like:

AUTH_COOKIE_MODE=d2
BROWSER_AUTH_TRANSPORT=cookie
REQUIRE_ACTIVE_SESSION=true

AUTH_COOKIE_ACCESS_NAME=__Host-medsync_at
AUTH_COOKIE_REFRESH_NAME=__Host-medsync_rt
AUTH_CSRF_COOKIE_NAME=__Host-medsync_csrf
AUTH_COOKIE_SECURE=true
AUTH_COOKIE_SAMESITE=lax
AUTH_COOKIE_DOMAIN=
AUTH_COOKIE_PATH=/
AUTH_COOKIE_MAX_AGE_MODE=session

CSRF_ENABLED=true
CORS_CREDENTIALS=true
CORS_ALLOWED_ORIGINS=https://app.<dominio>
CSRF_ALLOWED_ORIGINS=https://app.<dominio>

No copies valores de .env.local a produccion. .env.local puede tener rutas, puertos y secretos locales.

Variables que debes esperar en frontend

Ejemplo production-like:

VUE_APP_AUTH_COOKIE_MODE=d2
VUE_APP_BROWSER_AUTH_TRANSPORT=cookie
VUE_APP_CSRF_ENABLED=true
VUE_APP_CORE_URL_API=https://api.<dominio>/

En staging o produccion, VUE_APP_CORE_URL_API no debe usar http://.

Como se valida en navegador

En DevTools, despues de login:

Network

Authorization: NO debe existir
Cookie: puede existir
X-CSRF-Token: debe existir en POST/PUT/PATCH/DELETE

Application > Cookies

Esperado:

__Host-medsync_at    HttpOnly = true, Secure = true, Path = /
__Host-medsync_rt    HttpOnly = true, Secure = true, Path = /
__Host-medsync_csrf  HttpOnly = false, Secure = true, Path = /

Si no se usan __Host-*, debe existir una decision tecnica documentada. Aun asi, access y refresh deben ser HttpOnly y Secure=true.

Console

document.cookie

Esperado:

Puede aparecer __Host-medsync_csrf.
No deben aparecer __Host-medsync_at ni __Host-medsync_rt.

Storage

localStorage y sessionStorage no deben tener tokens, permisos, business ni tenant operacional.

Checklist de produccion para junior

Cada paso debe tener responsable, fecha y evidencia. Si falla un paso de seguridad, no marques production-ready.

Paso	Que se hace	Por que se hace	Como se valida	Error comun
1. Dominio	Definir el dominio real del producto.	Las cookies, CORS y CSRF dependen del dominio final.	Existe dominio aprobado por infraestructura/producto.	Usar dominios temporales y despues cambiar reglas sin repetir QA.
2. DNS	Crear `app.<dominio>` y `api.<dominio>`.	Frontend y API deben tener origenes claros.	`app` y `api` resuelven al destino correcto.	Mezclar `localhost`, IP directa y dominio real en la misma validacion.
3. TLS/HTTPS	Activar certificados validos.	Cookies `Secure=true` solo funcionan bien sobre HTTPS.	Browser muestra candado valido y no hay mixed content.	Probar D2 production-like sobre HTTP.
4. Backend env	Configurar D2, cookies, sesiones y seguridad en backend.	Backend decide como setear y leer cookies.	Arranque sin errores y QA de config D2 OK.	Copiar `.env.local` con valores locales o secretos.
5. Frontend env	Compilar con D2, cookie transport y API HTTPS.	El build frontend decide si usa cookies o legacy.	Build tiene `VUE_APP_BROWSER_AUTH_TRANSPORT=cookie`.	Build viejo sigue apuntando a HTTP o authorization.
6. CORS origins	Permitir solo `https://app.<dominio>`.	Cookies entre app/API necesitan credentials y allowlist exacta.	Origen permitido funciona y origen externo falla.	Usar `*` con credentials.
7. CSRF origins	Permitir solo origenes reales del frontend.	Las cookies se mandan solas; CSRF protege mutaciones.	Mutacion con CSRF pasa y sin CSRF falla con 403.	Apagar CSRF para “arreglar” login.
8. Secrets	Cargar secretos fuertes desde mecanismo seguro.	JWT, refresh, CSRF, password reset y DB dependen de secretos reales.	No hay placeholders ni secretos default.	Copiar secretos en docs, tickets o chats.
9. SMTP	Configurar correo real o sandbox aprobado.	Reset password necesita envio de OTP/codigo.	Forgot/reset password funciona end-to-end.	Marcar production-ready sin probar reset password.
10. Backups	Configurar backup DB/storage y restore.	Un despliegue productivo necesita recuperacion.	Restore probado en ambiente controlado.	Tener backup pero nunca probar restore.
11. Logs/alertas	Activar logs y alertas de auth/errores.	Seguridad necesita detectar 401/403/429/500, CSRF y CORS.	Alertas reciben eventos de prueba.	Logs imprimen cookies completas o tokens.
12. Deploy backend	Desplegar API con env aprobado.	Backend debe estar listo antes del frontend.	Health/smoke API OK.	API arranca con `AUTH_COOKIE_SECURE=false`.
13. Deploy frontend	Publicar build D2 en `https://app.<dominio>`.	El usuario entra por el frontend real.	App carga y apunta a `https://api.<dominio>/`.	Publicar build local o build legacy.
14. Smoke test	Probar login, session, refresh y logout.	Confirma que el flujo minimo esta vivo.	Login tokenless, session OK, refresh OK, logout limpia.	Probar solo login y olvidar refresh/logout.
15. Validar cookies	Revisar `HttpOnly`, `Secure`, `SameSite`, `Path` y nombres.	Es el control principal de D2.	DevTools muestra flags correctos.	Cookies sin `Secure` o access visible en `document.cookie`.
16. Validar storage	Revisar `localStorage` y `sessionStorage`.	No deben quedar secretos ni contexto sensible persistidos.	No hay token, refresh, JWT, permissions, business ni tenantOperational.	Confundir residuos viejos con estado actual y no limpiar.
17. Validar Network	Confirmar ausencia de `Authorization`.	D2 navegador no usa header auth legacy.	Requests API no tienen `Authorization`.	Mirar un request viejo cacheado o de otra pestana.
18. Reset password	Probar invalidacion de sesiones viejas.	Cambiar password debe cerrar access/refresh anteriores.	Password vieja falla, nueva funciona, sesion vieja recibe 401.	No probarlo por falta de SMTP sandbox.
19. Rollback	Ensayar rollback seguro.	Si algo falla, hay que salir sin abrir huecos.	Smoke post-rollback documentado.	Apagar CSRF mientras cookies siguen autenticando.
20. Go/no-go	Revisar evidencia y decidir.	Produccion requiere decision formal.	Checklist completo y riesgos aceptados por responsables.	Aprobar con critical/high abierto sin excepcion formal.

Checklist de 2 minutos production-like

Cuando abortar

Aborta rollout si ocurre cualquiera de estos puntos:

login devuelve access token o refresh token en JSON;
access/refresh aparecen en document.cookie;
cookies auth no son HttpOnly;
cookies auth no tienen Secure=true en HTTPS;
Network muestra Authorization;
CORS usa wildcard con credentials;
CSRF esta apagado;
reset password no invalida sesiones anteriores;
no hay backup/restore probado;
no hay forma clara de rollback.

Pendientes que no resuelve esta pagina

Esta guia no reemplaza:

pentest externo;
validacion production-like real;
decision de dominio final;
secret manager;
SMTP real o sandbox aprobado;
backup/restore real;
monitoreo productivo;
go/no-go formal.