Auditar quién crea y modifica registros en una base de datos es clave para sistemas seguros y trazables. Con Spring Security combinado con Spring Data JPA, puedes registrar automáticamente el username de cada usuario autenticado que inserta o modifica datos, sumando trazabilidad real a tus entidades.

¿Cómo extender la auditoría de fechas para registrar usuarios?

La entidad PizzaEntity ya cuenta con la anotación @EntityListeners, que apunta a dos listeners: una implementación propia llamada AuditPizzaListener y el AuditingEntityListener que Spring usa por defecto. Este último es el que permite auditar fechas y, ahora, también usuarios.

La clase PizzaEntity extiende de AuditableEntity, donde viven las columnas de auditoría. Para registrar el usuario, necesitas agregar dos atributos nuevos en esa clase base.

¿Qué atributos debes añadir en AuditableEntity?

Los atributos que sumas son simples strings mapeados a columnas específicas con sus respectivas anotaciones de auditoría.

• Atributo createdBy de tipo string, anotado con @Column(name = "created_by") y @CreatedBy.
• Atributo modifiedBy de tipo string, anotado con @Column(name = "modified_by") y @LastModifiedBy.
• Ambos funcionan en paralelo a los ya existentes @CreatedDate y @LastModifiedDate.

Con estas anotaciones, Spring sabe en qué columnas debe inyectar el username del usuario que crea o modifica una pizza [02:00].

¿Qué hace la anotación @CreatedBy en Spring Data JPA? Marca el atributo donde Spring guardará automáticamente el username del usuario autenticado al insertar un nuevo registro, sin que tengas que asignarlo manualmente.

¿Cómo implementar AuditorAware para capturar el usuario autenticado?

Para que @CreatedBy y @LastModifiedBy funcionen, Spring necesita saber de dónde sacar el usuario. Eso se resuelve implementando la interfaz AuditorAware<String> en una clase nueva.

Dentro del paquete audit, crea la clase AuditUsername y anótala con @Service para que viva en el contexto de Spring [03:10]. Esta clase implementa AuditorAware<String> y debe sobrescribir el método getCurrentAuditor, que devuelve un Optional<String>.

¿Cómo se obtiene el usuario desde el SecurityContextHolder?

El filtro de seguridad ya guarda la autenticación en el SecurityContextHolder mediante setAuthentication. Aquí haces lo opuesto: la recuperas con getAuthentication.

java Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

if (authentication == null || !authentication.isAuthenticated()) { return null; }

String username = authentication.getPrincipal().toString(); return Optional.of(username);

La validación de null y isAuthenticated es defensiva. Aunque las reglas de seguridad ya exigen rol de administrador y un JSON Web Token válido para modificar pizzas, conviene blindar la lógica [04:30].

El método getPrincipal devuelve un Object, por eso aplicas toString() para obtener el username como cadena. Ese valor envuelto en Optional.of es lo que Spring usará para llenar las columnas created_by y modified_by.

¿Qué es AuditorAware en Spring Data JPA? Es una interfaz que le dice a Spring cómo identificar al usuario actual. Implementarla permite que @CreatedBy y @LastModifiedBy se llenen automáticamente con el username autenticado.

¿Cómo verificar la auditoría de usuarios desde Postman y MySQL?

Una vez integrados los cambios, lanza la aplicación y prueba el flujo completo desde Postman para confirmar que la auditoría funciona.

¿Qué pasos seguir para probar el flujo de auditoría?

El proceso replica un caso real: autenticación, modificación y verificación en base de datos.

1. Genera el JSON Web Token con el usuario admin y contraseña admin123.
2. Copia el token del encabezado Authorization de la respuesta.
3. En la petición de actualizar pizza, cambia el tipo de autorización a Bearer Token y pega el JWT.
4. Modifica el body, por ejemplo agregando "sal" y "azúcar" a los ingredientes.
5. Lanza la petición y espera una respuesta 200.

Luego, en MySQL ejecuta SELECT * FROM pizzeria.pizza y verás que el registro de pepperoni tiene admin en la columna modified_by [06:15].

¿Por qué con el usuario customer no funciona la modificación?

Las reglas de seguridad restringen las operaciones de modificación al rol de administrador. Si intentas la misma petición con customer, el filtro la rechaza antes de llegar a la lógica de auditoría. Por eso la prueba se hace con admin.

Un buen ejercicio es crear una nueva pizza autenticado como administrador para confirmar cómo se llena la columna created_by al insertar un registro desde cero.

Este enlace entre Spring Data JPA y Spring Security convierte la auditoría en un mecanismo completo: ya no solo sabes cuándo se tocó un registro, sino quién lo hizo. ¿Has aplicado este patrón en alguno de tus proyectos? Cuéntalo en los comentarios.