Pedro Flores
Developer, happy husband and now a happy father!
Miryam Godoy
CODELAB
07/09/2024
https://meet.google.com/psd-mrvz-gzb
Para ver mejor las presentaciones y la pantalla de ejercicios
hay un link generado para pode acceder al google meet:
https://meet.google.com/psd-mrvz-gzb
Symfony proporciona muchas herramientas para proteger tu aplicación. Algunas herramientas de seguridad relacionadas con HTTP, como las cookies de sesión segura y la protección CSRF, se proporcionan de forma predeterminada.
Los permisos en Symfony siempre están vinculados a un objeto de usuario. Si necesitas proteger (partes de) tu aplicación, necesitas crear una clase de usuario. Esta es una clase que implementa UserInterface . Esta suele ser una entidad de Doctrine, pero también puedes usar una clase de usuario de seguridad dedicada.
Este proveedor de usuarios sabe cómo (re)cargar usuarios desde un almacenamiento (por ejemplo, una base de datos) en función de un "identificador de usuario" (por ejemplo, la dirección de correo electrónico o el nombre de usuario del usuario). La configuración anterior utiliza Doctrine para cargar la User entidad utilizando la email propiedad como "identificador de usuario".
La firewall es la ssección de config/packages/security.yaml es la más importante. Un "firewall" es su sistema de autenticación: el firewall define qué partes de su aplicación están protegidas y cómo sus usuarios podrán autenticarse (por ejemplo, formulario de inicio de sesión, token de API, etc.).
# config/packages/security.yaml
security:
# ...
firewalls:
# the order in which firewalls are defined is very important, as the
# request will be handled by the first firewall whose pattern matches
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
# a firewall with no pattern should be defined last because it will match all requests
main:
lazy: true
provider: users_in_memory
# activate different ways to authenticate
# https://symfony.com/doc/current/security.html#firewalls-authentication
# https://symfony.com/doc/current/security/impersonating_user.html
# switch_user: true
Solo hay un firewall activo en cada solicitud: Symfony usa la pattern clave para encontrar la primera coincidencia (también se puede buscar coincidencias por host u otros factores ). Aquí, todas las URL reales son manejadas por el main firewall (sin pattern clave significa que coincide con todas las URL).
El dev firewall es en realidad un firewall falso: se asegura de que no bloquees accidentalmente las herramientas de desarrollo de Symfony, que se encuentran bajo URL como /_profilery /_wdt.
A menudo, el usuario es desconocido (es decir, no ha iniciado sesión) cuando visita su sitio web por primera vez. Si visita su página de inicio ahora mismo, tendrá acceso y verá que está visitando una página detrás del firewall en la barra de herramientas:
Para visitar una URL bajo un firewall no es necesario que estés autenticado (por ejemplo, el formulario de inicio de sesión debe ser accesible o algunas partes de tu aplicación deben ser públicas). Por otro lado, todas las páginas que quieres que sepan que un usuario ha iniciado sesión deben estar bajo el mismo firewall. Por lo tanto, si quieres mostrar un mensaje que diga "Has iniciado sesión como..." en todas las páginas, todas deben estar incluidas en el mismo firewall.
Un mismo firewall puede tener varios modos de autenticación. En otras palabras, permite muchas formas de preguntar "¿Quién eres?" .
Durante la autenticación, el sistema intenta encontrar un usuario que coincida con el visitante de la página web. Tradicionalmente, esto se hacía mediante un formulario de inicio de sesión o un cuadro de diálogo HTTP básico en el navegador.
El proceso de autorización tiene dos vertientes diferenciadas:
Roles
Cuando un usuario inicia sesión, Symfony llama al getRoles() método de tu User objeto para determinar qué roles tiene este usuario. En la User clase que se generó anteriormente, los roles son una matriz que se almacena en la base de datos y a cada usuario siempre se le asigna al menos un rol ROLE_USER
// src/Entity/User.php
// ...
class User
{
/**
* @ORM\Column(type="json")
*/
private $roles = [];
// ...
public function getRoles(): array
{
$roles = $this->roles;
// guarantee every user at least has ROLE_USER
$roles[] = 'ROLE_USER';
return array_unique($roles);
}
}
Protección de patrones de URL (access_control)
La forma más básica de proteger una parte de tu aplicación es proteger un patrón de URL completo en security.yaml. Por ejemplo, para exigir ROLE_ADMIN que todas las URL que comiencen con /admin, puedes:
Protección de patrones de URL (access_control)
# config/packages/security.yaml
security:
# ...
firewalls:
# ...
main:
# ...
access_control:
# require ROLE_ADMIN for /admin*
- { path: '^/admin', roles: ROLE_ADMIN }
# or require ROLE_ADMIN or IS_AUTHENTICATED_FULLY for /admin*
- { path: '^/admin', roles: [IS_AUTHENTICATED_FULLY, ROLE_ADMIN] }
# the 'path' value can be any valid regular expression
# (this one will match URLs like /api/post/7298 and /api/comment/528491)
- { path: ^/api/(post|comment)/\d+$, roles: ROLE_USER }
Veamos un ejemplo
By Pedro Flores