Configurando la seguridad

Implementando el control de accesos

A partir de este momento debemos distinguir los diferentes tipos de usuario que manejamos, de modo de mostrarle a cada uno sólo lo que le corresponde.

Esto responde a dos necesidades complementarias:

1. Mantener la seguridad de la información, es decir, evitar que alguien vea algo que no debe.
2. Dar una experiencia acorde a cada usuario.

Para lograr estos objetivos necesitamos, ante todo, saber quién es el visitante.

Esto se consigue mediante un sistema de login.

Desde ya que podríamos implementar uno propio pero… ¿para qué esforzarnos si alguien ya lo ha hecho por nosotros? 😃

Crear una clase User

El primer paso en la implementación de un sistema de login es contar con una clase que maneje los usuarios: la clase User.

Arranquemos creándola con este comando:

php bin/console make:user

``En nuestro caso usaremos el campousernamecomo identificador y almacenaremos esta información en nuestra base de datos a través de Doctrine.

Al finalizar este comando tendremos cambios al modelo de datos, con lo cual, deberemos crear y ejecutar una nueva migración:

php bin/console make:migration
php bin/console doctrine:migrations:migrate

Y listo! Tenemos nuestra clase User completa 😃

Cómo crear un sistema de login

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

1. Elige la opción 1 (Login form authenticator)
2. 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.

Vamos a ver qué logramos con todo esto.

Apunta tu navegador a http://homestead.test/login.

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 templatetemplates/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.phpen tu editor favorito y busca el métodoonAuthenticationSuccess():

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
    {
        if ($targetPath = $this->getTargetPath($request->getSession(), $providerKey)) {
            return new RedirectResponse($targetPath);
        }

        // For example : return new RedirectResponse($this->urlGenerator->generate('some_route'));
        throw new \Exception('TODO: provide a valid redirect inside '.__FILE__);
    }

Y agrega estas líneas:

if ( in_array( 'ROLE_ADMIN', $token->getUser()->getRoles() ) ) {

   return new RedirectResponse($this->urlGenerator->generate('company'));
}

Antes del throw new \Exception.

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/Entitynotaremos que hay una clase que no está (Applicant) y una que sobra.

Ninguna de estas circunstancias debería llamar mucho la atención:

1. Aún no hemos llegado a desarrollar la parte del postulante.
2. 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

 Field type (enter ? to see all types) [string]:
 > relation

 What class should this entity be related to?:
 > User

 Relation type? [ManyToOne, OneToMany, ManyToMany, OneToOne]:
 > OneToOne

 Is the Company.owner property allowed to be null (nullable)? (yes/no) [yes]:
 > no

 Do you want to add a new property 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:

/**
* @ORM\OneToOne(targetEntity="App\Entity\User", cascade={"persist", "remove"})
* @ORM\JoinColumn(nullable=false)
*/
private $owner;

Claro que eso solo no afecta a la base de datos…

Para tener el modelo completo debes ejecutar:

php bin/console make:migration

Verificar el contenido desrc/Migrations/Version20200420172310.php

Y ejecutar php bin/console doctrine:migrations:migrate

Ahora debemos hacer algunas adaptaciones al código que ya teníamos.

Comencemos por algo sencillo: agreguemos un link para que el administrador pueda crear una nueva empresa desde el listado:

Para crear ese link vamos a utilizar una función de Twig (Lo que se conoce como un helper) de modo de no hardcodear(ver nota) URLs.

Abre el archivo templates/company/index.htmly agrega

<p><a href="{{ url('company_new') }}">Nueva empresa</a></p>

En la línea 23.

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")
*/
public function index(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:

public function buildForm(FormBuilderInterface $builder, array $options)
{
   $builder
       ->add('name')
       ->add('email')
       ->add('owner')
       ->add('submit', SubmitType::class, [
           'label' => 'Guardar',
       ])
   ;
}

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 __toStringen la clase User.

Ahora, como vemos, necesitamos crear primero los usuarios de cada empresa, para ello necesitaremos crear nuevos formularios.

Veámoslo en la próxima clase.

Nota

Si no tienes muy claro el concepto de hardcoding te recomiendo el curso de “Buenas Prácticas para la escritura de código”