Antes de empezar. En Servidor ya has trabajado usuarios persistentes, roles y control de propiedad. Hoy revisarás esos permisos con identidades distintas.
Se explica
25 minutos · explicación y demostración
Servidor 37–38 implementa usuarios persistentes, roles y autorización. Hoy utilizamos sus pruebas y casos de uso como criterios de revisión de la versión. Intermodular comprueba que un cambio de permisos tiene justificación, revisión y pruebas que se ejecutan; Servidor evalúa si la regla está bien implementada.
Una prueba con @WithMockUser prepara una identidad en Spring Security, pero no crea una fila en PostgreSQL. Un recorrido real necesita datos de prueba coherentes. Confundir ambas cosas produce rechazos que parecen fallos de permisos y son fallos de preparación.
Se trabaja
140 minutos · trabajo guiado sobre el producto compartido
Bloque A · Preparar un escenario reproducible
Crea, mediante el procedimiento de pruebas de Servidor, dos usuarios del mismo rol y un recurso que pertenezca a uno. Añade una cuenta con el rol administrativo previsto. Guarda ids y nombres ficticios en la configuración local de la colección; no presupongas id 1.
Bloque B · Recorrer la matriz
Prueba lectura, modificación y borrado como propietario y como otra persona. Ejecuta los casos de rol insuficiente y ausencia de identidad. Después de cada rechazo consulta los datos: un 403 debe impedir también el cambio. Contrasta cada resultado con la matriz, sin decidir permisos nuevos para acomodar el resultado observado.
Bloque C · Comprobar las pruebas automatizadas
Localiza los tests de seguridad de Servidor 38 y su ejecución en CI. Abre una rama de diagnóstico y provoca una regresión controlada en una regla. El test correspondiente debe fallar. Restaura la regla y comprueba verde; no fusiones la versión insegura ni cambies la aserción para ocultarla.
Bloque D · Revisar el cambio
En la PR enlaza la fila de la matriz, el test y la evidencia del rechazo. La persona revisora prueba al menos el caso de otro usuario del mismo rol. Describe qué datos persistentes necesita reproducirlo, para que la revisión no dependa de tu sesión del navegador.
Bloque E · Registrar el resultado
Relaciona los casos y el commit de Servidor que contiene la regla. Si aparece un defecto, usa una sola issue y una sola corrección para ambos módulos. Mantén separadas la causa técnica y la mejora necesaria del proceso de detección.
Cierre
15 minutos · comprobación del resultado
Al terminar la sesión: Has comprobado el acceso de personas con distintos roles y la protección de recursos ajenos. La revisión relaciona cada permiso con su caso de prueba y sus resultados.