La seguridad (o mejor dicho, el control de accesos) en Symfony se maneja a través del archivo de configuración: config/packages/security.yaml.
Hay mucho que puede tocarse dentro de este archivo para personalizar el comportamiento de la aplicación, sin embargo, para efectos de este curso estaremos bien con los valores por defecto.
Comencemos pues con lo que nos toca hacer:
++Paso 1: crear el formulario de login++
Usa el comando php bin/console make:auth
Elige la opción 1 (Login form authenticator)
Selecciona los valores por defecto hasta el final
Todos estos comandos crearán el código necesario para armar el formulario de login (Php y Twig) y procesar los datos enviados por el usuario y también harán las modificaciones necesarias en el archivo config/packages/security.yaml.
Si todo está en su lugar te encontrarás con una pantalla como esta:
Nada mal, ¿cierto? Bueno… si quieres ponerla más bonita, ¡adelante! Sólo debes meterle mano al template templates/security/login.html.twig
Bueno, hasta aquí todo fue magia… es hora de trabajar un poco :)
Si vuelves un poco atrás notarás que te quedó tarea para el hogar luego del comando make:auth
Finish the redirect "TODO"in the App\Security\LoginFormAuthenticator::onAuthenticationSuccess() method
Este método será invocado en forma automática cuando el login sea exitoso, es hora de decidir qué se deberá hacer.
Te podrás imaginar que cada usuario deberá ser redireccionado a alguna página de bienvenida especial según su rol.
Abre el archivo src/Security/LoginFormAuthenticator.php en tu editor favorito y busca el método onAuthenticationSuccess():
publicfunctiononAuthenticationSuccess(Request $request,TokenInterface $token, $providerKey){if($targetPath = $this->getTargetPath($request->getSession(), $providerKey)){returnnewRedirectResponse($targetPath);}// For example : return new RedirectResponse($this->urlGenerator->generate('some_route'));thrownew\Exception('TODO: provide a valid redirect inside '.__FILE__);}
De esta forma, cuando ingrese un usuario de tipo administrador será redireccionado al listado de empresas.
A medida que avancemos iremos agregando aquí las redirecciones propias de los otros tipos de usuario.
Creando nuestro usuario administrador
Para crear nuestro usuario administrador tendremos que utilizar algunos trucos (lamentablemente aquí no contamos con un comando mágico que haga todo).
Comienza por generar la contraseña escribiendo:
php bin/console security:encode-password admin
Copia el resultado que aparece en "Encoded password":
Y ejecuta el siguiente comando:
php bin/console doctrine:query:sql "INSERT INTO user (username, roles, password) VALUES ('admin', '[\"ROLE_ADMIN\"]', '\$argon2id\$v=19\$m=65536,t=4,p=1\$zHd8/9QmaFCkXITvBXNcKg\$kLZXWpuUrRH0FOhMaGbX4aZildau7gMym4PUHTTK44I');"
Con él estamos enviando un comando a la base de datos a través de Doctrine.
Es importante notar que los caracteres $ han sido escapados usando \$
Y ahora sí, puedes realizar un login con las credenciales admin:admin :)
Una vez pasado el login te encontrarás con el listado de empresas, desde allí podrás crear una nueva empresa usando los formularios definidos en la clase 6.
¡Genial!
Ahora es el momento de que un representante de la empresa ingrese y comience a cargar sus ofertas.
Lo que debemos hacer es generar un nuevo usuario para la empresa.
¿Pero cómo se vinculará nuestro usuario con la empresa? Es claro que algún cambio tendremos que hacer a nuestro modelo de datos.
Recordemos que el modelo original se veía así:
Pero si miramos nuestra base de datos o nuestro directorio src/Entity notaremos que hay una clase que no está (Applicant) y una que sobra.
Ninguna de estas circunstancias debería llamar mucho la atención:
Aún no hemos llegado a desarrollar la parte del postulante.
Al momento de comenzar nuestro análisis no habíamos tenido en cuenta los usuarios.
¿De qué forma se relacionan los usuarios con las otras entidades?
Para comenzar una empresa debe tener un usuario que la represente. La parte del postulante la veremos cuando llegue el momento.
Lo que debemos hacer pues es agregar una propiedad a nuestra clase.
Para ello usaremos un comando que ya vimos:
php bin/console make:entity Company
Nota como el comando tiene la inteligencia suficiente para darse cuenta de que no debe crear una nueva clase si no_ modificar_ la previamente existente.
De modo que lo que debes contestar es lo siguiente:
New property name(press <return> to stop adding fields):> owner
Fieldtype(enter ? to see all types)[string]:> relation
Whatclassshouldthis entity be related to?:>UserRelation type?[ManyToOne,OneToMany,ManyToMany,OneToOne]:>OneToOneIs the Company.owner property allowed to be null(nullable)?(yes/no)[yes]:> no
Do you want to add a newproperty to User so that you can access/update Company objects from it - e.g.$user->getCompany()?(yes/no)[no]:> no
¡Perfecto! Si abres el archivo src/Entity/Company notarás que ha aparecido una nueva propiedad:
Esta función (url) utiliza una técnica conocida como ruteo inverso: se genera una URL a partir del nombre de una ruta.
Fíjate en src/Controller/CompanyController.php como es la definición del método index:
/**
* @Route("/company", name="company")
*/publicfunctionindex(EntityManagerInterface $entityManager)El atributo name del annotation se utiliza como parámetro para el helper url para generar un link cuyo atributo href es http://homestead.test:8000/company/new
Ahora entonces si te diriges a[http://homestead.test:8000/company](http://homestead.test:8000/company)y das click en el link verás:
Algo falta ¿no? ¿Cómo se especifica el owner?
De hecho, si intentas crear una empresa usando este formulario te encontrarás con:
Tenemos que modificar ese formulario… no hay problema: Symfony al rescate :)
Primero eliminemos el formulario existente y luego usemos php bin/console make:form para re-construir nuestro CompanyType (No olvides agregar el botón de submit).
Y ahora, volvemos atrás al formulario, refrescamos la página y nos encontramos con:
¿Qué sucedió? Twig está tratando de generar HTML a partir de la definición del formulario:
Cada uno de los campos se genera a partir de la definición del widget (Objeto HTML) que le corresponde.
Si no aclaramos nada, Symfony lo adivina en base al tipo de datos del campo.
En el caso de owner, se trata de una entidad relacionada.
Symfony asocia este tipo de campos a una visualización en forma de desplegable:
Y para generar este desplegable es necesario saber cómo transformar un objeto de clase User en un string (el que se mostrará como opción seleccionable).
¿Cómo solucionarlo? Simple: hay que definir un método llamado __toString en la clase User.
Ahora, como vemos, necesitamos crear primero los usuarios de cada empresa, para ello necesitaremos crear nuevos formularios.
