Завантаження користувача: Постачальник користувачів

Окрім створення сутності, команда 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:
                # "login" - це ім'я раніше створеного маршруту
                login_path: login
                check_path: 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">
            <!-- "login" - це ім'я раніше створеного маршруту -->
            <form-login login-path="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');

    // "login" - це ім'я раніше створеного маршруту
    $mainFirewall->formLogin()
        ->loginPath('login')
        ->checkPath('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. Система безпеки (тобто аутентифікатор 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">
    {# ... поля логіну #}

    <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. Див. довідник конфігурації , щоб дізнатися більше.

Віддалені користувачі

Окрім аутентифікації сертифікатів клієнта, існує багато інших модулів веб-сервера, який попередньо аутентифікує користувача (наприклад, 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
25
26

# config/packages/security.yaml
security:
    # ви маєте використати менеджер аутентифікатора
    enable_authenticator_manager: true

    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
26
27
28
29

<!-- 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 спроб входу за хвилину -->
            <login-throttling/>

            <!-- сконфігурувати максимум спроб входу (за хвилину) -->
            <login-throttling max-attempts="3"/>

            <!-- сконфігурувати максимум спроб входу за заданий період часу -->
            <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
15
16
17
18
19
20
21
22

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

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

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

    // за замовчуванням, функція дозволяє 5 спроб входу за хвилину
    $mainFirewall->loginThrottling();

    // сконфігурувати максимум спроб входу (за хвилину)
    $mainFirewall->loginThrottling()
        ->maxAttempts(3)
    ;

    // сконфігурувати максимум спроб входу за заданий період часу
    $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. Зареєструйте слухача або підписника подій, щоб виконувати користувацьку логіку. Наступна інформація доступна в класі події:

// src/EventListener/LogoutSubscriber.php namespace AppEventListener;

use SymfonyComponentEventDispatcherEventSubscriberInterface; use SymfonyComponentHttpFoundationRedirectResponse; use SymfonyComponentRoutingGeneratorUrlGeneratorInterface; use SymfonyComponentSecurityHttpEventLogoutEvent;

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\Component\Security\Core\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');

    // ...
}

Ви можете використати 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

Запускається після завершення "імперсонації іншого". Див. Як імперсонувати користувача.

Аутентифікація (Ідентифікація користувача/вхід у систему)

Авторизація (Відмова у доступі)