Registro y login de usuarios en Symfony

Configurar el registro y el inicio de sesión en Symfony es uno de esos pasos que parecen complejos, pero que el framework resuelve casi por completo con dos comandos del MakerBundle. Aquí aprenderás cómo crear el sistema de autenticación, registrar usuarios y proteger la ruta /admin con roles, partiendo de una entidad User ya existente.

¿Cómo se genera el sistema de autenticación en Symfony?

Todo arranca desde la consola. Symfony ofrece un asistente interactivo que crea las clases, vistas y configuraciones necesarias para el login.

El comando inicial es php bin/console make:auth [01:05]. Al ejecutarlo, el asistente pregunta:

• Tipo de autenticación: eliges formulario de inicio de sesión (opción 1).
• Nombre de la clase autenticadora: se sugiere uno por defecto, basta con quitar la palabra custom y dejar algo como AppAuthenticator.
• Nombre del controlador: el sugerido suele ser SecurityController.
• Configurar la URL de cierre de sesión: respondes que sí.

Con eso, Symfony genera la clase autenticadora, el controlador de seguridad, la vista de login y ajusta la configuración de seguridad. Dentro de src/Security/AppAuthenticator.php queda un comentario indicando dónde configurar la redirección posterior al login exitoso [02:30], algo que se personaliza más adelante según la página de destino que quieras.

¿Qué hace make:auth en Symfony? Genera un sistema completo de inicio de sesión: clase autenticadora, controlador, plantilla Twig y rutas de login y logout, todo conectado al firewall de seguridad.

¿Cómo crear el formulario de registro de usuarios?

El segundo comando es php bin/console make:registration-form [03:10]. Este asistente también hace preguntas clave para definir el comportamiento del registro.

• Validar correos únicos para evitar cuentas duplicadas: sí.
• Enviar email de verificación tras el registro: no, porque el foco es un panel administrativo simple.
• Iniciar sesión automáticamente después del registro: sí, para mejorar la experiencia.

El resultado es una actualización en la entidad User, un nuevo form type, un controlador de registro y una plantilla Twig dedicada. Con eso ya tienes el flujo completo: una persona puede registrarse, quedar autenticada y volver al sitio sin pasos adicionales.

¿Qué archivos crea Symfony al generar el registro?

Al revisar el estado del repositorio con Git, encontrarás cambios en la entidad User, un nuevo RegistrationFormType, un RegistrationController y la vista correspondiente. Esa trazabilidad es útil para entender qué tocó el MakerBundle y qué puedes ajustar tú.

¿Cómo restringir el acceso a la ruta /admin con roles?

La protección del panel administrativo no requiere escribir lógica nueva. Symfony ya trae la regla preparada en config/packages/security.yaml, solo está comentada.

Dentro de ese archivo existe la sección access_control [05:20]. Allí encontrarás una línea comentada que indica que la ruta /admin requiere el rol ROLE_ADMIN. Basta con descomentarla, guardar y refrescar el navegador para que el acceso quede bloqueado a usuarios sin permisos.

El flujo de prueba se ve así:

1. Visitas /admin sin sesión y obtienes acceso denegado.
2. Te registras con un correo como i@app.com y contraseña 123456789.
3. Marcas la casilla de términos y envías el formulario.
4. El sistema te autentica, pero al intentar entrar a /admin sigue denegando el acceso.

¿Por qué sigue bloqueado si ya iniciaste sesión? Porque el usuario recién creado no tiene el rol requerido. En la base de datos, la columna roles aparece vacía y access_control exige ROLE_ADMIN.

¿Qué es ROLE_ADMIN en Symfony? Es una etiqueta de permiso que asignas a un usuario en la columna roles de la tabla user. Sin ese rol, el firewall bloquea cualquier ruta protegida bajo access_control.

¿Cómo asignar el rol administrativo a un usuario?

Directamente en la base de datos editas la columna roles del usuario y colocas el valor en formato JSON:

["ROLE_ADMIN"]

Al guardar el cambio, Symfony detecta una modificación en la sesión y te pide volver a autenticarte. Ingresas con i@app.com y 123456789, y ahora sí entras al panel administrativo con permisos completos.

¿Dónde se cierra la sesión y cómo se prueba el flujo?

La plantilla generada incluye un botón de cierre de sesión, y la barra de depuración de Symfony ofrece un enlace directo a logout [07:45]. Esto te permite alternar entre usuarios autenticados y anónimos para validar que las restricciones funcionen.

Con esto compruebas el ciclo completo: registro, autenticación, asignación de rol y protección de rutas. Tres conceptos clave que conviene tener claros:

• Autenticador: la clase que valida credenciales y mantiene la sesión activa.
• Firewall: la capa que intercepta peticiones y decide si pasan o no.
• Access control: la regla que conecta una ruta con un rol específico.

Replica el ejercicio en tu proyecto, prueba con dos usuarios distintos (uno con ROLE_ADMIN y otro sin rol) y comparte en los comentarios qué redirección configurarías tras un login exitoso.