La misión
Convierte tu agenda en un sistema para un pequeño equipo: registro y login con contraseña hasheada, recuperación por correo simulada, y tres roles —propietario, editor, solo lectura— con una matriz de permisos que TÚ defines antes de pedir una línea. Cada contacto pasa a tener dueño y visibilidad por equipo. El objetivo oculto del proyecto: que la auditoría final encuentre cero puertas traseras. Si «funciona» pero cualquiera puede editar al otro, falló.
La ruta, seis tiempos
Ruta del proyecto 3
1 · Matriz de permisos (M9, 15 min)
ESPECIFICACION.md abre con la tabla: operación × rol, sin casillas en blanco. El «propietario» puede invitar y eliminar equipo; el «editor» crear y editar del equipo; «solo lectura» ver lo compartido. Toda regla «excepto cuando…» se escribe explícita o se convierte en bug futuro.2 · Modelo de datos que lo soporta (M7)
usuarios, sesiones/tokens, pertenencia a equipo con rol, contacto con equipo_id. La IA propone y tú revisas relaciones y claves (M7-OA03): ¿qué pasa con los contactos si se va el único propietario? La respuesta va en la especificación.3 · Prompt de autenticación con candados (M9+M10)
El prompt del registro/login con la lista de no-negociables: hash con librería estándar, nada de contraseñas en log, límite de intentos, sesión que expira. Cada candado es un criterio de aceptación medible, no un deseo.4 · Forzar permisos EN CADA ENDPOINT (M6)
La trampa clásica: el menú del frontend oculta los botones y parece que funciona. La revisión verifica lo que el menú no puede hacer por ti: que cada endpoint cheque rol Y propiedad, no solo «está logueado».5 · Auditoría de las tres puertas (M10+cnf)
Token caducado en la laptop compartida, usuario 2 llamando directo al endpoint de borrado del 1, contraseña «123456» en el registro. PRUEBAS.md documenta las tres puertas: si alguna se abrió, el hallazgo vale oro.6 · Publicar con secretos en entorno (M16)
Variables de entorno para clave de sesión y credenciales de base, HTTPS encendido (la contraseña por http en claro es el detalle que demolería todo el módulo 10), URL pública y repo.
Paso 1 de 6
El prompt de autenticación (con los no-negociables)
La línea 6 y la prueba de propiedad cruzada: donde mueren los sistemas a medias
Capa nueva del proyecto 3: autenticacion y roles. Stack del documento maestro.\n\nNo negociables (cada uno es un criterio de aceptacion VERIFICABLE):\n1. contrasenas con hash de libreria estandar (bcrypt/argon segun stack), nunca en claro\n2. la contrasena nunca aparece en logs ni en mensajes de error, ni en la respuesta del API\n3. limite de intentos de login (5 por correo/hora) con espera creciente\n4. sesion con token de duracion limitada; el cliente guarda el token segun la practica\n correcta del stack y lo manda en cada peticion\n5. recuperacion: token de un solo uso con expiracion corta (simulable por correo local)\n6. TODOS los endpoints protegidos chequean: token valido + rol adecuado + propiedad del\n recurso. El frontend que oculta botones es UX, no defensa: la barrera vive aca.\n\nMatriz de permisos (definida por mi en ESPECIFICACION.md, pegarla completa aqui):\n[pega tu tabla operacion x rol literal]\n\nPruebas por endpoint: sin token (401), rol equivocado (403), propiedad cruzada\n(el editor del equipo A toca un contacto del equipo B -> 403), token caducado.\n\nImplementa, corre todo, muestra diff y salida. No toques la logica de contactos de\nla capa 2 sin mostrarme el diff de lo que cambia.Qué entrega este proyecto
| Entregable | Barra alta de este proyecto |
|---|---|
| ESPECIFICACION.md | la matriz operación × rol sin casillas en blanco y el caso del propietario que se va |
| HALLAZGOS.md | el endpoint que dejaba pasar al usuario equivocado, el login que logueaba la contraseña |
| PRUEBAS.md | las tres puertas auditadas + propiedad cruzada por endpoint crítico |
| App publicada | dos cuentas reales de prueba editando cada una lo suyo, nada más |
Prueba
Tu sistema: el menú muestra el botón «eliminar» solo al propietario, y los demás no lo ven. ¿Es suficiente para cumplir la matriz?
Almacena la contraseña con hash (no en claro) y ya: con eso la autenticación del proyecto está bien protegida.
Empieza por el punto que la IA no puede escribir por ti: la matriz operación × rol completa, en ESPECIFICACION.md. Luego el prompt de capa con los seis no-negociables. Cierra con la auditoría de las tres puertas Y la propiedad cruzada documentadas —si la primera prueba te deja limpio, prueba más sucio.
Un sistema de permisos es una decisión de negocio escrita dos veces: una en la especificación, otra en cada endpoint.
Tu texto se guarda sólo en este dispositivo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.