Загрузка пользователя: Поставщик пользователей

Кроме создания сущности, команда make:user также добавляет конфигурацию для поставщика пользователей в вашу конфигурацию безопасности:

1
2
3
4
5
6
7
8
9

# config/packages/security.yaml
security:
    # ...

    providers:
        app_user_provider:
            entity:
                class: App\Entity\User
                property: email

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->

        <provider name="app_user_provider">
            <entity class="App\Entity\User" property="email"/>
        </provider>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13

// config/packages/security.php
use App\Entity\User;
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    // ...

    $security->provider('app_user_provider')
        ->entity()
            ->class(User::class)
            ->property('email')
    ;
};

Этот поставщик пользователей знает, как (пере)загружать пользователей из хранилища (например, БД), основываясь на "идентификаторе пользователя" (например, адресе почты или имени пользователя). Конфигурация выше использует Doctrine для загрузки сущности User, используя свойство email как "user identifier".

Поставщики пользователей используются в нескольких местах во время жизненного цикла безопасности:

Загрузка пользователя, основываясь на идентификаторе

Во время входа (или любой другой аутентификации), поставщик загружает пользователя, основываясь на его идентификаторе пользователя. Некоторые другие функции, вроде имитации пользователя и Запомнить меня также используют это.

Перезагрузка пользователя из сессии

В начале каждого запроса, пользователь загружается из сессии (кроме случаев, когда ваш брандмауэр stateless). Поставщик "обновляет" пользователя (например, снова делает запрос к БД для свежих данных), чтобы убедиться, что вся информация пользователя обновлена (и, если необходимо, пользователь деаутентифицируется/выводится из системы, если что-то изменилось). См. Поставщики пользователей Безопасности, чтобы узнать больше об этом процессе.

Symfony поставляется с несколькими встроенными поставщиками пользователей:

Поставщик пользователей сущности

Загружает пользователей из БД, используя Doctrine;

Поставщик пользователей LDAP

Загружает пользователей с LDAP-сервера;

Поставщик пользователей памяти

Загружает пользователей из файла конфигурации;

Цепной постащик пользователей

Слияет два или более поставщика пользоваталей в нового поставщика пользователей.

Встроенные поставщики пользователей покрывают наиболее распространенные задачи приложений, но вы также можете создать собственного пользовательского поставщика пользователей.

Регистрация пользователя: Хеширование паролей

Множество приложений требуют входа в систему с помощью пароля. Для таких приложений SecurityBundle предоставляет хеширование паролей и верификацию функциональности.

Для начала, убедитесь, что ваш класс User реализует PasswordAuthenticatedUserInterface:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// src/Entity/User.php

// ...
use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;

class User implements UserInterface, PasswordAuthenticatedUserInterface
{
    // ...

    /**
     * @return строку с хешированным паролем для этого пользователя
     */
    public function getPassword(): string
    {
        return $this->password;
    }
}

Затем, сконфигурируйте, какой хешировщик паролей должен быть использован для этого класса пользователя. Если ваш файл security.yaml еще не был предварительно сконфигурирован, то make:user должен был сделать это за вас:

1
2
3
4
5
6
7

# config/packages/security.yaml
security:
    # ...
    password_hashers:
        # Использовать нативный хешировщик паролей, который автоматически выбирает и мигрирует лучший
        # возможный алгоритм хеширования (начиная с Symfony 5.3 это "bcrypt")
        Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->
        <!-- Использовать нативный хешировщик паролей, который автоматически выбирает и мигрирует лучший
             возможный алгоритм хеширования (начиная с Symfony 5.3 это "bcrypt") -->
        <password-hasher class="Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface" algorithm="auto"/>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13

// config/packages/security.php
use App\Entity\User;
use Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface;

return static function (SecurityConfig $security) {
    // ...

    // Использовать нативный хешировщик паролей, который автоматически выбирает и мигрирует лучший
    // возможный алгоритм хеширования (начиная с Symfony 5.3 это "bcrypt")
    $security->passwordHasher(PasswordAuthenticatedUserInterface::class)
        ->algorithm('auto')
    ;
};

Теперь, когда Symfony знает как вы хотите хешировать пароли, вы можете использовать сервис UserPasswordHasherInterface, чтобы делать это до сохранения ваших пользователей в базу данных:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// src/Controller/RegistrationController.php
namespace App\Controller;

// ...
use Symfony\Component\PasswordHasher\Hasher\UserPasswordHasherInterface;

class RegistrationController extends AbstractController
{
    public function index(UserPasswordHasherInterface $passwordHasher)
    {
        // ... например, получить данные пользователя из формы регистрации
        $user = new User(...);
        $plaintextPassword = ...;

        // хешировать пароль (основываясь на конфигурации security.yaml для класса $user)
        $hashedPassword = $passwordHasher->hashPassword(
            $user,
            $plaintextPassword
        );
        $user->setPassword($hashedPassword);

        // ...
    }
}

1
2

$ composer require symfonycasts/verify-email-bundle
$ php bin/console make:registration-form

Вы также можете вручную хешировать пароль, выполнив:

1

$ php bin/console security:hash-password

Прочтите больше обо всех доступных хешироващиках и миграции паролей в Хеширование и верификация паролей.

Извлечение конфигурации брандмауэра для запроса

Если вам нужно получить конфигурацию брандмауэра, совпавшего с заданным запросом, используйте сервис Security:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// src/Service/ExampleService.php
// ...

use Symfony\Bundle\SecurityBundle\Security;
use Symfony\Component\HttpFoundation\RequestStack;

class ExampleService
{
    private Security $security;

    public function __construct(Security $security, RequestStack $requestStack)
    {
        $this->requestStack = $requestStack;
        // Избегайте вызова getFirewallConfig() в конструкторе: авторизация может быть еще
        // не завершена. Вместо этого, сохраните весь объект Security.
        $this->security = $security;
    }

    public function someMethod()
    {
        $request = $this->requestStack->getCurrentRequest();
        $firewallName = $this->security->getFirewallConfig($request)?->getName();

        // ...
    }
}

Форма входа

Большинство сайтов имеют форму входа, где пользователи проходят аутентификацию, используя идентификатор (например, адрес почты или имя пользователя) и пароль. Этот функционал предоставлен аутентификатором формы входа.

Для начала, создайте контроллер для формы входа:

1
2
3
4

$ php bin/console make:controller Login

 created: src/Controller/LoginController.php
 created: templates/login/index.html.twig

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// src/Controller/LoginController.php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class LoginController extends AbstractController
{
    #[Route('/login', name: 'login')]
    public function index(): Response
    {
        return $this->render('login/index.html.twig', [
            'controller_name' => 'LoginController',
        ]);
    }
}

Затем, подключите аутентификатор формы входа, используя настройку form_login:

1
2
3
4
5
6
7
8
9
10
11

# config/packages/security.yaml
security:
    # ...

    firewalls:
        main:
            # ...
            form_login:
                # "app_login" - это имя ранее созданного маршрута
                login_path: app_login
                check_path: app_login

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->
        <firewall name="main">
            <!-- "app_login" - это имя ранее созданного маршрута -->
            <form-login login-path="app_login" check-path="login"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    // ...

    $mainFirewall = $security->firewall('main');

    // "app_login" - это имя ранее созданного маршрута
    $mainFirewall->formLogin()
        ->loginPath('app_login')
        ->checkPath('app_login')
    ;
};

После подключения, система безопасности перенаправляет неаутентифицированных посетителей на login_path, если они пробуют попасть в защищенное место (это поведение можно настроить, используя точки входа аутентификации ).

Отредактируйте контроллер входа, чтобы отобразить форму входа:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// ...
+ use Symfony\Component\Security\Http\Authentication\AuthenticationUtils;

  class LoginController extends AbstractController
  {
      #[Route('/login', name: 'login')]
-     public function index(): Response
+     public function index(AuthenticationUtils $authenticationUtils): Response
      {
+         // получить ошибку входа, если она есть
+         $error = $authenticationUtils->getLastAuthenticationError();
+
+         // последнее имя пользователя, введенное пользователем
+         $lastUsername = $authenticationUtils->getLastUsername();
+
          return $this->render('login/index.html.twig', [
-             'controller_name' => 'LoginController',
+             'last_username' => $lastUsername,
+             'error'         => $error,
          ]);
      }
  }

Не позволяйте этому контроллеру запутать вас. Его работа только отображать форму: аутентификатор form_login позаботится об отправке формы автоматически. Если пользовател отправляет невалидный адрес почты или пароль, этот аутентификатор сохранит ошибку и перенаправит обратно к этому контроллеру, где мы прочтем ошибку (используя AuthenticationUtils), чтобы она могла быть отражена пользователю.

Наконец, создайте или обновите шаблон:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{# templates/login/index.html.twig #}
{% extends 'base.html.twig' %}

{# ... #}

{% block body %}
    {% if error %}
        <div>{{ error.messageKey|trans(error.messageData, 'security') }}</div>
    {% endif %}

    <form action="{{ path('login') }}" method="post">
        <label for="username">Email:</label>
        <input type="text" id="username" name="_username" value="{{ last_username }}"/>

        <label for="password">Password:</label>
        <input type="password" id="password" name="_password"/>

        {# Если вы хотите контролировать URL, по которому перенаправляется пользователь при успешном входе
        <input type="hidden" name="_target_path" value="/account"/> #}

        <button type="submit">login</button>
    </form>
{% endblock %}

Форма может выглядеть как угодно, но обычно она следует некоторым соглашениям:

• Элемент <form> отправляет POST маршруту login, так как вы сконфигурировали это как check_path под ключом form_login в security.yaml;
• Поле имя пользователя (или любого "идентификатора" пользователя, вроде почты) имеет имя _username, а поле пароля - _password.

Вот и все! При отправке формы, система безопасности автоматически читает _username и параметр POST _password, загружает пользователя из поставщика пользователей, проверяет параметры доступа пользователя и либо аутентифицирует его, либо отправляет обратно в форму входа, где можно отобразить ошибку.

Подведем итог всего процесса:

1. Пользователь пробует получить доступ к защищенному ресурсу (например, /admin);
2. Брандмауэр инициирует процесс аутентификации, перенаправляя пользователя к форме входа (/login);
3. Страница /login отображает форму входа по маршруту и контроллеру, созданным в этом примере;
4. Пользователь отправляет форму входа /login;
5. Система безопасности (т.e. аутентификатор form_login) перехватывает запрос, проверяет параметры доступа, отправленные пользователем, аутентифицирует пользователя, если они правильные, и отправляет пользователя обратно в форму входа - если нет.

1
2
3
4
5
6
7
8
9
10

# config/packages/security.yaml
security:
    # ...

    firewalls:
        secured_area:
            # ...
            form_login:
                # ...
                enable_csrf: true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->

        <firewall name="secured_area">
            <!-- ... -->
            <form-login enable-csrf="true"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    // ...

    $mainFirewall = $security->firewall('main');
    $mainFirewall->formLogin()
        // ...
        ->enableCsrf(true)
    ;
};

1
2
3
4
5
6
7
8
9
10

{# templates/security/login.html.twig #}

{# ... #}
<form action="{{ path('login') }}" method="post">
    {# ... the login fields #}

    <input type="hidden" name="_csrf_token" value="{{ csrf_token('authenticate') }}">

    <button type="submit">login</button>
</form>

Вход JSON

Некоторые приложения предоставляют API, защищенный с помощью токенов. Такие приложения могут использовать конечную точку, предоставляющую эти токены, основываясь на имени пользователя (или почте) и пароле. Аутентификатор входа JSON помогает вам фнукционально создвать это.

Включите аутентификтор, используя настройку json_login:

1
2
3
4
5
6
7
8
9
10

# config/packages/security.yaml
security:
    # ...

    firewalls:
        main:
            # ...
            json_login:
                # api_login - это маршрут, который мы создадим ниже
                check_path: api_login

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->
        <firewall name="main">
            <json-login check-path="api_login"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    // ...

    $mainFirewall = $security->firewall('main');
    $mainFirewall->jsonLogin()
        ->checkPath('api_login')
    ;
};

Аутентификатор запускается, когда клиент запрашивает check_path. Для начала, создайте контроллер для этого пути:

1
2
3

$ php bin/console make:controller --no-template ApiLogin

 created: src/Controller/ApiLoginController.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// src/Controller/ApiLoginController.php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class ApiLoginController extends AbstractController
{
    #[Route('/api/login', name: 'api_login')]
    public function index(): Response
    {
        return $this->json([
            'message' => 'Welcome to your new controller!',
            'path' => 'src/Controller/ApiLoginController.php',
        ]);
    }
}

Этот контроллер входа будет вызван после того, как аутентификатор успешно аутентифицирует пользователя. Вы можете получить аутентифицированного пользователя, сгенерировать токен (или то, что вам надо вернуть) и вернуть JSON-ответ:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// ...
+ use App\Entity\User;
+ use Symfony\Component\Security\Http\Attribute\CurrentUser;

  class ApiLoginController extends AbstractController
  {
      #[Route('/api/login', name: 'api_login')]
-     public function index(): Response
+     public function index(#[CurrentUser] ?User $user): Response
      {
+         if (null === $user) {
+             return $this->json([
+                 'message' => 'missing credentials',
+             ], Response::HTTP_UNAUTHORIZED);
+         }
+
+         $token = ...; // как-то создать API-токен для $user
+
          return $this->json([
-             'message' => 'Welcome to your new controller!',
-             'path' => 'src/Controller/ApiLoginController.php',
+             'user'  => $user->getUserIdentifier(),
+             'token' => $token,
          ]);
      }
  }

Вот и все! Подытожим процесс:

1. Клиент (например, фронтенд) делает запрос POST с заголовком Content-Type: application/json к /api/login с username (даже если ваш идентификатор на самом деле - почта) и ключами password:

   1
   2
   3
   4

   {
       "username": "dunglas@example.com",
       "password": "MyPassword"
   }

2. Система безопасности перехватывает запрос, проверяет отправленные права доступа пользователя и аутентифицирует его. Если права доступа некорректные, возвращается JSON ответ HTTP 401 Неавторизовано, в других случаях запускается ваш контроллер;

3. Ваш контроллер создает корреный ответ:

   1
   2
   3
   4

   {
       "user": "dunglas@example.com",
       "token": "45be42..."
   }

Базовый HTTP

Аутентификация базового HTTP - это стандартизированный фреймворк HTTP-аутентификации. Он запрашивает права доступа (имя пользователя и пароль), используя диалог в браузере и аутентификатор базового HTTP Symfony верифицирует эти права.

Добавьте ключ http_basic к вашему брандмауэру, чтобы включить аутентификатор базового HTTP:

1
2
3
4
5
6
7
8
9

# config/packages/security.yaml
security:
    # ...

    firewalls:
        main:
            # ...
            http_basic:
                realm: Secured Area

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->
        <firewall name="main">
            <http-basic realm="Secured Area"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $mainFirewall = $security->firewall('main');
    $mainFirewall->httpBasic()
        ->realm('Secured Area')
    ;
};

Вот и все! Каждый раз, когда неаутентифицированный пользователь будет пытаться посетить защищенную страницу, Symfony будет информировать браузер, что ему нужно начать базовую HTTP аутентификацию (используя заголовок ответа WWW-Authenticate). Затем, аутентификатор верифицирует права доступа и аутенитфицирует пользователя.

Вход по ссылке

Вход по ссылке - это безпарольный механизм аутентификации. Пользователь будет получать ссылку с коротким сроком жизни (например, по почте), которая аутентифицирует их на веб-сайте.

Вы можете узнать все об этом аутентификаторе в Как использовать беспарольную аутентификацию ссылки входа в систему.

Токены доступа

Токены доступа часто используются в контексте API. Пользователь получает токен с сервера авторизации, который его аутентифицирует.

Вы можете узнать все об этом аутентификторе в Как использовать аутентификацию токенов доступа.

Сертификаты клиентов X.509

При использовании сертификатов клиентов, ваш веб-сервер делает всю аутентификацию сам. Аутентификатор X.509, предоставленный Symfony, извлекает почту из "уникального имени" (DN) сертификата клиента. Затем, он использует эту почту в качестве идентификатора пользователя в поставщике пользователей.

Для начала, сконфигурируйте ваш веб-сервер, чтобы подключить верификацию сертификатов клиентов, и показать DN сертификатов приложению Symfony:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

server {
    # ...

    ssl_client_certificate /path/to/my-custom-CA.pem;

    # включить верификацию сертификатов клиентов
    ssl_verify_client optional;
    ssl_verify_depth 1;

    location / {
        # передать приложению DN как "SSL_CLIENT_S_DN"
        fastcgi_param SSL_CLIENT_S_DN $ssl_client_s_dn;

        # ...
    }
}

1
2
3
4
5
6
7

# ...
SSLCACertificateFile "/path/to/my-custom-CA.pem"
SSLVerifyClient optional
SSLVerifyDepth 1

# передать DN приложению
SSLOptions +StdEnvVars

Затем, включите аутентификатор X.509, используя x509 в вашем брандмауэре:

1
2
3
4
5
6
7
8
9

# config/packages/security.yaml
security:
    # ...

    firewalls:
        main:
            # ...
            x509:
                provider: your_user_provider

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->

        <firewall name="main">
            <!-- ... -->
            <x509 provider="your_user_provider"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $mainFirewall = $security->firewall('main');
    $mainFirewall->x509()
        ->provider('your_user_provider')
    ;
};

По умолчанию, Symfony извлекает адрес почты из DN двумя способами:

1. В начале, она пробует параметр сервера SSL_CLIENT_S_DN_Email, который обнажен с помощью Apache;
2. Если он не установлен (например, при использовании Nginx), она использует SSL_CLIENT_S_DN, и сопоставляет значение следующего emailAddress=.

Вы можете настроить имена обоих параметров под ключом x509. См. the configuration reference , чтобы узнать больше.

Удаленные пользователи

Кроме аутентификации сертификатов клиента, существует много других модулей веб-сервера, который предварительно аутентифицируют пользователя (например, kerberos). Удаленный аутентификатор пользователей предоставляет базовую интеграцию для таких сервисов.

Такие модули часто обнажают аутентифицированного пользователя в переменной окружения REMOTE_USER. Аутентификатор удаленного пользователя использует это значение в качестве идентификатора пользователя, чтобы загрузить соответствующего пользователя.

Включите аутентификацию удаленного пользователя, используя ключ remote_user:

1
2
3
4
5
6
7

# config/packages/security.yaml
security:
    firewalls:
        main:
            # ...
            remote_user:
                provider: your_user_provider

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <firewall name="main">
            <remote-user provider="your_user_provider"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $mainFirewall = $security->firewall('main');
    $mainFirewall->remoteUser()
        ->provider('your_user_provider')
    ;
};

Ограничение попыток входа

Symfony предоставляет базовую защиту от атак входа грубой силы. Вы должны включить ее, используя настройку login_throttling:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# config/packages/security.yaml
security:

    firewalls:
        # ...

        main:
            # ...

            # по умолчанию, функция позволяет 5 попыток входа за минуту
            login_throttling: null

            # сконфигуровать максимум попыток входа (за минуту)
            login_throttling:
                max_attempts: 3

            # сконфигурировать максимум попыток входа за заданный период времени
            login_throttling:
                max_attempts: 3          # в минуту ...
                # interval: '15 minutes' # ... или в пользовательский период времени

            # использовать пользовательский ограничитель скорости через его ID сервиса
            login_throttling:
                limiter: app.my_login_rate_limiter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <!-- вы должны использовать менеджер аутентификатора -->
    <config enable-authenticator-manager="true">
        <!-- ... -->

        <firewall name="main">
            <!-- по умолчанию, функция позволяет 5 попыток входа за минуту
                 max-attempts: (необязательно) Вы можете сконфигурировать максимум попыток ...
                 interval:     (необязательно) ... и их временной промежуток. -->
            <login-throttling max-attempts="3" interval="15 minutes"/>

            <!-- использовать пользовательский ограничитель времени через его ID сервиса -->
            <login-throttling limiter="app.my_login_rate_limiter"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $security->enableAuthenticatorManager(true);

    $mainFirewall = $security->firewall('main');

    // по умолчанию, функция позволяет 5 попыток входа за минуту
    $mainFirewall->loginThrottling()
        // ->maxAttempts(3)         // Необязательно: Вы можете сконфигурировать максимум попыток ...
        // ->interval('15 minutes') // ... и их временной промежуток.
    ;
};

Внутренне, Symfony использует компонент Rate Limiter, который по умолчанию использует кэш Symfony, чтобы сохранять предыдущие попытки входа. Однако, вы можете реализовать пользовательское хранилище .

Попытки входа ограничиваются в max_attempts (по умолчанию: 5) неудачных запросов для IP address + username и 5 * max_attempts неудачных запросов для IP address. Второе ограничение защищает от того, чтобы хакер использовал несколько имен пользователя, обходя первое ограничение, не нарушая работу нормальных пользователей в больших сетях (таких как офисы).

Если вам нужен более сложный алгоритм ограничений, создайте класс, реализующий RequestRateLimiterInterface (или используйте DefaultLoginRateLimiter) и установите опцию limiter в ее ID сервиса:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# config/packages/security.yaml
framework:
    rate_limiter:
        # определите 2 ограничителя (один для username+IP, второй - для IP)
        username_ip_login:
            policy: token_bucket
            limit: 5
            rate: { interval: '5 minutes' }

        ip_login:
            policy: sliding_window
            limit: 50
            interval: '15 minutes'

services:
    # наш пользовательский ограничитель
    app.login_rate_limiter:
        class: Symfony\Component\Security\Http\RateLimiter\DefaultLoginRateLimiter
        arguments:
            # globalFactory - ограничитель для IP
            $globalFactory: '@limiter.ip_login'
            # localFactory - ограничитель для username+IP
            $localFactory: '@limiter.username_ip_login'

security:
    firewalls:
        main:
            # использовать пользовательский ограничитель по его ID сервиса
            login_throttling:
                limiter: app.login_rate_limiter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:framework="http://symfony.com/schema/dic/symfony"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/symfony
        https://symfony.com/schema/dic/symfony/symfony-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <framework:config>
        <framework:rate-limiter>
            <!-- определите 2 ограничителя (один для username+IP, второй - для IP) -->
            <framework:limiter name="username_ip_login"
                policy="token_bucket"
                limit="5"
            >
                <framework:rate interval="5 minutes"/>
            </framework:limiter>

            <framework:limiter name="ip_login"
                policy="sliding_window"
                limit="50"
                interval="15 minutes"
            />
        </framework:rate-limiter>
    </framework:config>

    <srv:services>
        <!-- наш пользовательский ограничитель -->
        <srv:service id="app.login_rate_limiter"
            class="Symfony\Component\Security\Http\RateLimiter\DefaultLoginRateLimiter"
        >
            <!-- 1ый аргумент - ограничитель для IP -->
            <srv:argument type="service" id="limiter.ip_login"/>
            <!-- 2ой аргумент - ограничитель для username+IP -->
            <srv:argument type="service" id="limiter.username_ip_login"/>
        </srv:service>
    </srv:services>

    <config>
        <firewall name="main">
            <!-- использовать пользовательский ограничитель по его ID сервиса -->
            <login-throttling limiter="app.login_rate_limiter"/>
        </firewall>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// config/packages/security.php
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Reference;
use Symfony\Component\Security\Http\RateLimiter\DefaultLoginRateLimiter;
use Symfony\Config\FrameworkConfig;
use Symfony\Config\SecurityConfig;

return static function (ContainerBuilder $container, FrameworkConfig $framework, SecurityConfig $security) {
    $framework->rateLimiter()
        ->limiter('username_ip_login')
            ->policy('token_bucket')
            ->limit(5)
            ->rate()
                ->interval('5 minutes')
    ;

    $framework->rateLimiter()
        ->limiter('ip_login')
            ->policy('sliding_window')
            ->limit(50)
            ->interval('15 minutes')
    ;

    $container->register('app.login_rate_limiter', DefaultLoginRateLimiter::class)
        ->setArguments([
            // 1ый аргумент - ограничитель для IP
            new Reference('limiter.ip_login'),
            // 2ой аргумент - ограничитель для username+IP
            new Reference('limiter.username_ip_login'),
        ]);

    $security->firewall('main')
        ->loginThrottling()
            ->limiter('app.login_rate_limiter')
    ;
};

Программный выход из системы

Вы можете вывести пользователя из системы программно, используя метод logout() помощника Security:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// src/Controller/SecurityController.php
namespace App\Controller\SecurityController;

use Symfony\Bundle\SecurityBundle\Security;

class SecurityController
{
    public function someAction(Security $security): Response
    {
        // вывести пользователя из системы под текущим брандмауэром
        $response = $security->logout();

        // вы также можете отключить выход из системы csrf
        $response = $security->logout(false);

        // ... вернуть $response (если установлен) или, к примеру, перенаправить на домашнюю страницу
    }
}

Пользователь будет выведен из системы под брандмауэром запроса. Если запрос не находится за брандмауэром, будет вызвано \LogicException.

Настройка выхода

В некоторых случаях вам нужно будет выполнить дополнительную логику после выхода из системы (например, инвалидировать некоторые токены), или вам может захотеться настроить то, что происходит после выхода. Во время выхода из системы, запускается LogoutEvent. Зарегистрируйте слушателя или подписчика событий, чтобы выполнять пользовательскую логику:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

// src/EventListener/LogoutSubscriber.php
namespace App\EventListener;

use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\Routing\Generator\UrlGeneratorInterface;
use Symfony\Component\Security\Http\Event\LogoutEvent;

class LogoutSubscriber implements EventSubscriberInterface
{
    public function __construct(
        private UrlGeneratorInterface $urlGenerator
    ) {
    }

    public static function getSubscribedEvents(): array
    {
        return [LogoutEvent::class => 'onLogout'];
    }

    public function onLogout(LogoutEvent $event): void
    {
        // получить токен безопасности сесии, из которой сейчас будет выполнен выход
        $token = $event->getToken();

        // получить текущий запрос
        $request = $event->getRequest();

        // получить текущий ответ, если он уже установлен другим слушателем
        $response = $event->getResponse();

        // сконфигурировать пользовательский ответ выхода из системы на домашнюю страницу
        $response = new RedirectResponse(
            $this->urlGenerator->generate('homepage'),
            RedirectResponse::HTTP_SEE_OTHER
        );
        $event->setResponse($response);
    }
}

Извлечение пользователя из сервиса

Если вам нужно получить залогиненого пользователя из сервиса, используйте сервис Security:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// src/Service/ExampleService.php
// ...

use Symfony\Bundle\SecurityBundle\Security;

class ExampleService
{
    private $security;

    public function __construct(Security $security)
    {
        // Избегайте вызова getUser() в констуркторе: авторизация может быть еще
        // не выполнена. Вместо этого, сохраните весь объект Security.
        $this->security = $security;
    }

    public function someMethod()
    {
        // возвращает объект User или null, если он не аутентифицирован
        $user = $this->security->getUser();

        // ...
    }
}

Извлечение пользователя в шаблоне

В шаблоне Twig объект пользователя доступен через переменную app.user благодаря глобальной переменной приложения Twig :

1
2
3

{% if is_granted('IS_AUTHENTICATED_FULLY') %}
    <p>Email: {{ app.user.email }}</p>
{% endif %}

Роли

Когда пользователь выполняет вход, Symfony вызывает метод getRoles() в вашем объекте User, чтобы определить, какие роли имеет пользователь. В классе User, который был сгенерирован ранее, роли - это массив, хранящийся в БД, и каждый пользователь всегда имеет хотя бы одну роль: ROLE_USER:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// src/Entity/User.php

// ...
class User
{
    #[ORM\Column(type: 'json')]
    private $roles = [];

    // ...
    public function getRoles(): array
    {
        $roles = $this->roles;
        // гарантировать, что каждый пользователь имеет хотя бы ROLE_USER
        $roles[] = 'ROLE_USER';

        return array_unique($roles);
    }
}

Это хорошо по умолчанию, но вы можете сделать что угодно, чтобы определить, какие роли должен иметь пользователь. Единственное правило - каждая роль должна начинаться с префикса ROLE_ - иначе, все не будет работать, как ожидается. Кроме этого, роль - это просто строка, и вы можете придумать все, что вам нужно (например, ROLE_PRODUCT_ADMIN).

Вы будете использовать роли далее, чтобы предоставлять доступ к конкретным разделам вашего сайта.

1
2
3
4
5
6
7

# config/packages/security.yaml
security:
    # ...

    role_hierarchy:
        ROLE_ADMIN:       ROLE_USER
        ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->

        <role id="ROLE_ADMIN">ROLE_USER</role>
        <role id="ROLE_SUPER_ADMIN">ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH</role>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    // ...

    $security->roleHierarchy('ROLE_ADMIN', ['ROLE_USER']);
    $security->roleHierarchy('ROLE_SUPER_ADMIN', ['ROLE_ADMIN', 'ROLE_ALLOWED_TO_SWITCH']);
};

1
2
3
4
5
6

// ПЛОХО - $user->getRoles() не будет знать об иерархии ролей
$hasAccess = in_array('ROLE_ADMIN', $user->getRoles());

// ХОРОШО - использование нормальных методов безопасности
$hasAccess = $this->isGranted('ROLE_ADMIN');
$this->denyAccessUnlessGranted('ROLE_ADMIN');

Добавьте код для отказа в доступе

Существует два способа отказать в доступе к чему-то:

1. access_control в security.yaml позволяет вам защитить паттерны URL (например, /admin/*). Проще, но менее гибко;
2. в вашем контроллере (или другом коде) .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# config/packages/security.yaml
security:
    # ...

    firewalls:
        # ...
        main:
            # ...

    access_control:
        # требовать ROLE_ADMIN для /admin*
        - { path: '^/admin', roles: ROLE_ADMIN }

        # или требовать ROLE_ADMIN или IS_AUTHENTICATED_FULLY для /admin*
        - { path: '^/admin', roles: [IS_AUTHENTICATED_FULLY, ROLE_ADMIN] }

        # значение 'path' может быть любым валидным регулярным выражением
        # (это будет совпадать с URL вроде /api/post/7298 и /api/comment/528491)
        - { path: ^/api/(post|comment)/\d+$, roles: ROLE_USER }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->

        <firewall name="main">
            <!-- ... -->
        </firewall>

        <!-- требовать ROLE_ADMIN для /admin* -->
        <rule path="^/admin" role="ROLE_ADMIN"/>

        <!-- или требовать ROLE_ADMIN или IS_AUTHENTICATED_FULLY для /admin* -->
        <rule path="^/admin">
            <role>ROLE_ADMIN</role>
            <role>IS_AUTHENTICATED_FULLY</role>
        </rule>

        <!-- значение 'path' может быть любым валидным регулярным выражением
             (это будет совпадать с URL вроде /api/post/7298 и /api/comment/528491) -->
        <rule path="^/api/(post|comment)/\d+$" role="ROLE_USER"/>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $security->enableAuthenticatorManager(true);

    // ...
    $security->firewall('main')
    // ...
    ;

    // требовать ROLE_ADMIN для /admin*
    $security->accessControl()
        ->path('^/admin')
        ->roles(['ROLE_ADMIN']);

    // или требовать ROLE_ADMIN или IS_AUTHENTICATED_FULLY для /admin*
    $security->accessControl()
        ->path('^/admin')
        ->roles(['ROLE_ADMIN', 'IS_AUTHENTICATED_FULLY']);

    // значение 'path' может быть любым валидным регулярным выражением
    // (это будет совпадать с URL вроде /api/post/7298 и /api/comment/528491)
    $security->accessControl()
        ->path('^/api/(post|comment)/\d+$')
        ->roles(['ROLE_USER']);
};

1
2
3
4
5
6
7
8
9
10

# config/packages/security.yaml
security:
    # ...

    access_control:
        # сопоставляет с /admin/users/*
        - { path: '^/admin/users', roles: ROLE_SUPER_ADMIN }

        # сопоставляет с /admin/* кроме всего другого, совпадающего с правилом выше
        - { path: '^/admin', roles: ROLE_ADMIN }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config>
        <!-- ... -->

        <rule path="^/admin/users" role="ROLE_SUPER_ADMIN"/>
        <rule path="^/admin" role="ROLE_ADMIN"/>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// config/packages/security.php
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    // ...

    $security->accessControl()
        ->path('^/admin/users')
        ->roles(['ROLE_SUPER_ADMIN']);

    $security->accessControl()
        ->path('^/admin')
        ->roles(['ROLE_ADMIN']);
};

1
2
3
4
5
6
7
8
9
10

// src/Controller/AdminController.php
// ...

public function adminDashboard(): Response
{
    $this->denyAccessUnlessGranted('ROLE_ADMIN');

    // или добавить необязательное сообщение, которое видят разработчики
    $this->denyAccessUnlessGranted('ROLE_ADMIN', null, 'User tried to access a page without having ROLE_ADMIN');
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// src/Controller/AdminController.php
// ...

use Symfony\Component\Security\Http\Attribute\IsGranted;

#[IsGranted('ROLE_ADMIN')]
class AdminController extends AbstractController
{
    #[IsGranted('ROLE_SUPER_ADMIN')]
    public function adminDashboard(): Response
    {
        // ...
    }
}

1
2
3

{% if is_granted('ROLE_ADMIN') %}
    <a href="...">Delete</a>
{% endif %}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// src/SalesReport/SalesReportManager.php

  // ...
  use Symfony\Component\Security\Core\Exception\AccessDeniedException;
+ use Symfony\Component\Security\Core\Security;

  class SalesReportManager
  {
+     private $security;

+     public function __construct(Security $security)
+     {
+         $this->security = $security;
+     }

      public function generateReport()
      {
          $salesData = [];

+         if ($this->security->isGranted('ROLE_SALES_ADMIN')) {
+             $salesData['top_secret_numbers'] = rand();
+         }

          // ...
      }

      // ...
  }

Разрешение незащищенного доступа (т.н. анонимные пользователи)

Когда посетитель еще не вошел на ваш сайт, он рассматривается, как "неаутентифицированный" и не имеет никаких ролей. Это заблокирует ему доступ к вашим страницам, если вы определили правило access_control.

В конфигурации access_control вы можете использовать атрибут безопасности PUBLIC_ACCESS, чтобы исключить некоторые маршруты для неаутентифицированного доступа (например, страницу входа):

1
2
3
4
5
6
7
8
9
10
11

# config/packages/security.yaml
security:
    enable_authenticator_manager: true

    # ...
    access_control:
        # разрешить неаутентифицированным полльзователям доступ к форме входа
        - { path: ^/admin/login, roles: PUBLIC_ACCESS }

        # но требовать аутентификации для всех других админских маршрутов
        - { path: ^/admin, roles: ROLE_ADMIN }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<!-- config/packages/security.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<srv:container xmlns="http://symfony.com/schema/dic/security"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:srv="http://symfony.com/schema/dic/services"
    xsi:schemaLocation="http://symfony.com/schema/dic/services
        https://symfony.com/schema/dic/services/services-1.0.xsd
        http://symfony.com/schema/dic/security
        https://symfony.com/schema/dic/security/security-1.0.xsd">

    <config enable-authenticator-manager="true">
        <!-- ... -->

        <access-control>
            <!-- разрешить неаутентифицированным полльзователям доступ к форме входа -->
            <rule path="^/admin/login" role="PUBLIC_ACCESS"/>

            <!-- но требовать аутентификации для всех других админских маршрутов -->
            <rule path="^/admin" role="ROLE_ADMIN"/>
        </access-control>
    </config>
</srv:container>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// config/packages/security.php
use Symfony\Component\Security\Core\Authorization\Voter\AuthenticatedVoter;
use Symfony\Config\SecurityConfig;

return static function (SecurityConfig $security) {
    $security->enableAuthenticatorManager(true);
    // ....

    // разрешить неаутентифицированным полльзователям доступ к форме входа
    $security->accessControl()
        ->path('^/admin/login')
        ->roles([AuthenticatedVoter::PUBLIC_ACCESS])
    ;

    // но требовать аутентификации для всех других админских маршрутов
    $security->accessControl()
        ->path('^/admin')
        ->roles(['ROLE_ADMIN'])
    ;
};

Разрешение доступа анонимным пользователям в пользовательском избирателе

Если вы используете пользовательский избиратель, вы можете разрешить анонимным пользователям доступ, проверив, не установлен ли в токене пользователь:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// src/Security/PostVoter.php
namespace App\Security;

// ...
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authentication\User\UserInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;

class PostVoter extends Voter
{
    // ...

    protected function voteOnAttribute(string $attribute, $subject, TokenInterface $token): bool
    {
        // ...

        if (!$token->getUser() instanceof UserInterface) {
            // пользователь не аутентифицирован, например, позволить ему видеть
            // только публичные посты
            return $subject->isPublic();
        }
    }
}

Установка индивидуальных разрешений пользователей

Большинство приложений требуют более конкретных правил доступа. К примеру, пользователь должен иметь возможность редактировать только собственные комментарии в блоге. Избиратели позволяют вам писать любую бизнес-логику, необходимую вам для определения доступа. Использование этих избирателей схоже с проверками доступа, основанного на ролях, реализуемыми в предыдущих главах. Прочтите Как использовать избирателей для проверки разрешений пользователей, чтобы узнать, как реализовать собственного избирателя.

Проверка, выполнил ли пользователь вход (IS_AUTHENTICATED_FULLY)

Если вы хотите проверить только выполнил ли пользователь вход (но вам не важны роли), у вас есть два варианта.

Первый, если вы дали каждому пользователю ROLE_USER, вы можете проверить эту роль.

Другой - вы можете использовать специальный "атрибут" вместо роли:

1
2
3
4
5
6
7
8

// ...

public function adminDashboard(): Response
{
    $this->denyAccessUnlessGranted('IS_AUTHENTICATED_FULLY');

    // ...
}

Вы можете использовать IS_AUTHENTICATED_FULLY везде, где используются роли: вроде access_control или в Twig.

IS_AUTHENTICATED_FULLY не является ролью, но ведет себя как она, и каждый пользователь, выполнивший вход, будет иметь его. На самом деле, существуют специальные атрибуты вроде этого:

• IS_AUTHENTICATED_REMEMBERED: Все пользователи, выполнившие вход, имеют его, даже если они в системе из-за "куки запомнить меня". Даже если вы не используете функционал запомнить меня, вы можете использовать это, чтобы проверять, выполнил ли пользователь вход.
• IS_AUTHENTICATED_FULLY: Похоже на IS_AUTHENTICATED_REMEMBERED, но мощнее. Пользователи, которые в системе только из-за "куки запомнить меня", будут иметь IS_AUTHENTICATED_REMEMBERED, но не будут иметь IS_AUTHENTICATED_FULLY.
• IS_REMEMBERED: Только пользователи, аутентифицированные с использованием функционала запомнить меня, (т.е. куки запомнить меня).
• IS_IMPERSONATOR: Когда текущий пользователь имперсонализирует другого пользователя в этой сессии, атрибут будет совпадать.

Сравнение пользователей вручную с EquatableInterface

Или, если вам нужно больше контроля над процессом "сравнения пользователей", сделайте так, чтобы ваш класс User реализовывал EquatableInterface. После этого, ваш метод isEqualTo() будет вызываться при сравнении пользователей, вместо базовой логики.

События аутентификации

CheckPassportEvent

Запускается после того, как аутентификатор создал паспорт безопасности . Слушатели этого события проводят реальные проверки аутентификации (вроде проверки паспорта, валидации CSRF-токена и т.д.)

AuthenticationTokenCreatedEvent

Запускается после валидации паспорта и того, как аутентификатор создал токен безопасности (и пользователя). Это может быть использовано в продвинутых случаях применения, где вам нужно изменять созданный токен (например, для мульти-факторной аутентификации).

AuthenticationSuccessEvent

Запускается когда аутентификация приближается к успеху. Это последнее событие, которое может привести к неудачной аутентификации, вызвав AuthenticationException.

LoginSuccessEvent

Вызывается после того, как аутентификация была полностью успешна. Слушатели этого события могут изменять ответ, отправленный пользователю.

LoginFailureEvent

Запускается после вызова AuthenticationException во время аутентификации. Слушатели этого события изменяют ответ ошибки и отправляют его обратно пользователю.

Другие события

LogoutEvent

Запускается прямо перед тем, как пользователь выходит из вашего приложения. См. .

TokenDeauthenticatedEvent

Запускается когда пользователь деаутентифицирован, например, из-за изменения пароля. См. Поставщики пользователей Безопасности.

SwitchUserEvent

Запускается после завершения "имитации другого". См. Как имперсонализировать пользователя.

Аутентификация (Идентификация пользователя/вход в систему)

Авторизация (Отказ в доступе)