Bonjour,

Je travail actuellement sur mon premier projet Symfony 2 et j'utilise le fameux FOSUserBundle (Soit dit en passant, je me demande réellement si il simplifie les choses.. lol).

Je bute actuellement sur la mise en place d'un système de double firewall. Je m'explique :
    - FrontOffice : Je souhaite avoir une gestion utilisateur avec connexion etc... ceux-ci pourront par exemple écrire des commentaires, noter des articles, etc...
    - BackOffice : Je souhaite que si l'utilisateur connecté sur le Front possède au moins un rôle au dessus de ROLE_USER, est accès à un bouton "Administration". Ce dis bouton le redirigera vers la page d'accueil de l'administration (/admin) en passant par un deuxième formulaire de connexion, d'où le second firewall sur "/admin".

Actuellement lorsque je rentre "/admin", mon formulaire de connexion au BackOffice me redirige vers la page d'accueil du Front et pas sur la page d'accueil du Back qui est normalement la page referer. Je ne peux donc pas accéder à l'administration car je suis sans cesse redirigé soit vers le formulaire de connexion du Back ou soit vers la page d'accueil du Front. J'ai l'impression que les deux firewall se marchent dessus.

Je n'arrive pas à trouver mon erreur, je viens donc quémander l'avi des experts Sf2 . Pourriez vous m'aider s'il vous plaît ? (Je précise que j'utilise le Bundle JMSI18nRoutingBundle pour gérer la traduction de mes routes suivant la locale, si il existe mieux n'hésitez pas à le rajouter comme remarque).

Voici mes fichiers :

app/config/security.yml

security:
    encoders:
        FOS\UserBundle\Model\UserInterface: sha512

    role_hierarchy:
        ROLE_MODERATOR:   ROLE_USER
        ROLE_ADMIN:       ROLE_MODERATOR
        ROLE_SUPER_ADMIN: ROLE_ADMIN

    providers:
        fos_userbundle:
            id: fos_user.user_provider.username
            #id: fos_user.user_provider.username_email

    firewalls:
        login:
            pattern:   ^(users|utilisateurs)/(login$|connexion$|register|enregistrer|resetting|reinitialiser)  # Les adresses de ces pages sont login, register et resetting
            anonymous: true
        login_admin:
            pattern:   ^/admin/(users|utilisateurs)/(login|connexion)$  # Les adresses de ces pages sont login, register et resetting
            anonymous: true
        admin:
            pattern: ^/admin
            form_login:
                provider: fos_userbundle
                csrf_provider: form.csrf_provider
                login_path: fos_admin_user_security_login 
                check_path: fos_admin_user_security_check
            logout:
                path: fos_admin_user_security_logout
                target: /
            anonymous: false
        main:
            pattern: ^/
            form_login:
                provider: fos_userbundle
                csrf_provider: form.csrf_provider
                login_path: fos_user_security_login 
                check_path: fos_user_security_check
            logout:
                path: fos_user_security_logout
                target: /
            anonymous: true

    access_control:
        - { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/admin/(users|utilisateurs)/(login|connexion)$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/admin/, role: ROLE_MODERATOR }

app/config/config.yml  FOSUserBundle

#FOS User Bundle
fos_user:
    db_driver: orm
    firewall_name: main
    user_class: Ceva\Bundle\UserBundle\Entity\User
    group:
        group_class: Ceva\Bundle\UserBundle\Entity\Group
        form:
            type:    ceva_group_form              # Nouveau formulaire qui surcharge le formulaire d'inscription

app/config/routing.yml

ceva_admin_user:
    resource: "@CevaUserBundle/Resources/config/routing_admin.yml"
    prefix:   /admin/users

ceva_user:
    resource: "@CevaUserBundle/Resources/config/routing.yml"
    prefix:   /users

src/Ceva/Bundle/UserBundle/Resources/config/routing.yml

# FOS Security
fos_user_security_login:
    pattern: /login
    defaults: { _controller: FOSUserBundle:Security:login }

fos_user_security_check:
    pattern: /check
    defaults: { _controller: FOSUserBundle:Security:check }
    requirements:
        _method: POST

fos_user_security_logout:
    pattern: /logout
    defaults: { _controller: FOSUserBundle:Security:logout }

src/Ceva/Bundle/UserBundle/Resources/config/routing_admin.yml

# FOS Admin Security
fos_admin_user_security_login:
    pattern: /login
    defaults: { _controller: FOSUserBundle:Security:login }

fos_admin_user_security_check:
    pattern: /check
    defaults: { _controller: FOSUserBundle:Security:check }
    requirements:
        _method: POST

fos_admin_user_security_logout:
    pattern: /logout
    defaults: { _controller: FOSUserBundle:Security:logout }

Merci.

 

-
Edité par Aratyorr 7 avril 2014 à 13:13:16

je ne comprend pas le double login perso, soit il a des droits ton utilisateur, soit il en a pas, pourquoi devrait-il s'enregistrer deux fois

dans l'accueil pour tout le monde, tu peux caler une div spécifique selon le rôle de l'utilisateur

genre:

{% if is_granted(ROLE_ADMIN) %}

 <div id="qui va bien pour les admin">

   <a= href="le lien pour faire une action spécifique aux admins>Salut l'admin!</a>

  <a href=""> Patati Patata</a>

</div>

{% end if %}

si l'utilisateur n'a pas le rôle souhaité, ce bloc ne lui sera jamais envoyé

Je voulais faire une interface BackOffice indépendante du FrontOffice avec ces propres fonctions de connexion et déconnexion pour augmenter la sécurité et avoir un template différent.

Après peut-être que je me fourvoie   !

Et je ne veux pas qu'il s'enregistre deux fois, je veux que les deux formulaires tapent dans la même table "fos_users". Mais je veux que pour accéder au Back, il saisisse à nouveau son mot de passe dans un formulaire de login type admin pour augmenter la sécurité.

-
Edité par Aratyorr 7 avril 2014 à 13:28:23

ben tu fais un bloc comme indiqué ci dessus le renvoyant vers la page d'accueil du backoffice, cette page a son propre layout ainsi que toutes les autres pages du back office, mais tout le monde se connecte sur la page d'accueil du front

ps: je ne dis pas que ma solution est la seule ou la plus appropriée, je dis juste qu'elle marche:))

En soit ce que tu me propose je l'ai déjà fait, car j'ai pu travailler sur le BackOffice avec cette méthode depuis plusieurs jours. Mais je me disais qu'un double login est plus sécurisé pour éviter que des utilisateurs mal intentionnée utilise le compte connecté automatiquement d'une connaissance et puisse aller sans restriction sur le BackOffice. La méthode dont je te parle est utilisée sur beaucoup de CMS actuels.

PS : Je ne dis pas que cette méthode est la meilleure non plus

-
Edité par Aratyorr 7 avril 2014 à 13:36:03

et si l'admin  ou le moderator se barre de sa chaise alors qu'il est sur le back office et qu'un gonze trololo à sa place, tu fais quoi?

nan, les utilisateurs avancés ont des responsabilités, à un moment, faut qu'ils les assument

mébon

Sur ce coup tu as raison, mais la question n'est pas là. 

Déjà la session Backoffice doit avoir une limite de validité dans le temps, mais bref ça c'est autre chose. La vrai problématique, c'est surtout de permettre la connexion avec un cookie sur le FrontOffice sans rendre le BackOffice vulnérable. Tu as beau avoir un cookie sur la machine pour te connecter au Front, pour accéder au BackOffice tu te dois de saisir de nouveau ton mot de passe.

-
Edité par Aratyorr 7 avril 2014 à 13:59:02

je honnis les cookies, sauf ceux qu'on mange

les cookies n'ont rien à voir avec la sécurité à mon sens, mais je peux me tromper

Bref..

Sinon personne pour m'aider sur ce système de firewall SF2, Siouplaiiiiit ??? 

Aratyorr a écrit:

Tu as beau avoir un cookie sur la machine pour te connecter au Front, pour accéder au BackOffice tu te dois de saisir de nouveau ton mot de passe.

Même si ça ne répond pas exactement à ce que tu veux, tu peux regarder IS_AUTHENTICATED_FULLY : au moins, tu seras obligé de saisir le mot de passe pour aller plus loin, si tu as été authentifié de manière automatique.

LvParis a écrit:

Même si ça ne répond pas exactement à ce que tu veux, tu peux regarder IS_AUTHENTICATED_FULLY : au moins, tu seras obligé de saisir le mot de passe pour aller plus loin, si tu as été authentifié de manière automatique.

Tout d'abord merci pour ta réponse. Où mettrai tu cette condition, sur l'affichage du lien Administration ? Ou plutôt dans le controller de la page d'accueil du BackOffice ? Et si false alors redirection vers le render du login plutôt que l'accueil du back ?

-
Edité par Aratyorr 7 avril 2014 à 15:53:12

Vraiment personne pour configurer un double firewall ? C'est si dur que ça ? Snifff 

Petit up, je suis toujours bloqué..

Problème résolu, non sans mal ! Je posterai la solution demain pour les intéressés.

J'aimerai bien la réponse, oui.

Sinon, le authenticated_fully, tu le mets pour rentrer dans le backoffice.

Aratyorr a écrit:

Problème résolu, non sans mal ! Je posterai la solution demain pour les intéressés.

volontiers, j'apprendrais quelque chose, donc c'est toujours ça de gagné!:)

Voici la solution !

Pour la petit histoire :

En faite lors de mon premier coup d'essai je n'étais pas bien loin... Je n'avais juste pas percuté qu'après avoir créé un second firewall lié au même provider, il fallait avoir un template de login différent pour pouvoir modifier le chemin du "login check" dans l'action du formulaire de login. Donc voici la marche à suivre pour réaliser un BackOffice avec une sécurité indépendante du Front Office avec FOSUserBundle (Adaptable à un UserBundle personnel) .

Préambule : Ce tutoriel suppose que vous avez FOSUserBundle installé et configuré accompagné d'une classe UserBundle qui le surcharge. Veuillez vous référez au tutoriel de winzou pour en savoir plus. Ce tutoriel utilisera Acme comme auteur du UserBundle.

1) Premièrement la déclaration des routes. Votre architecture de routing n'est pas importante, ce qui compte c'est connaitre le chemin final de vos url de connexions afin de pouvoir construire vos access_control par la suite. Pour ma part je fonctionne avec deux fichiers de routing par bundle, un pour le Frontoffice : "routing.yml" prefixé par "/" et un pour le BackOffice : "routing_admin.yml" préfixé par "/admin". Voici les routes à déclarer :

Acme/UserBundle/Resources/config/routing.yml

# Route de connexion au FrontOffice
fos_user_security_login:
    pattern: /login
    defaults: { _controller: FOSUserBundle:Security:login }

# Route de vérification de connexion au FrontOffice
fos_user_security_check:
    pattern: /check
    defaults: { _controller: FOSUserBundle:Security:check }
    requirements:
        _method: POST

# Route de déconnexion du FrontOffice
fos_user_security_logout:
    pattern: /logout
    defaults: { _controller: FOSUserBundle:Security:logout }

Acme/UserBundle/Resources/config/routing_admin.yml

# Route de connexion au Backoffice
fos_admin_user_security_login:
    pattern:  /login
    defaults: { _controller: FOSUserBundle:Security:login }

# Route de vérification de connexion au Backoffice
fos_admin_user_security_check:
    pattern:  /check
    defaults: { _controller: FOSUserBundle:Security:check }
    requirements:
        _method: POST

# Route de déconnexion du Backoffice
fos_admin_user_security_logout:
    pattern:  /logout
    defaults: { _controller: FOSUserBundle:Security:logout }

2) Ensuite nous devons créer nos deux firewalls indépendants qui vont chacun gérer un espace, soit le Front, soit le Back, dans le fichier security.yml de Symfony :

app/config/security.yml

jms_security_extra:
    secure_all_services: false
    expressions: true

security:
    # Hashage des mot de passes
    encoders:
        FOS\UserBundle\Model\UserInterface: sha512

    # Droits des comptes
    role_hierarchy:
        ROLE_MODERATOR:   ROLE_USER
        ROLE_ADMIN:       ROLE_MODERATOR
        ROLE_SUPER_ADMIN: ROLE_ADMIN

    # Fournisseur des utilisateurs
    providers:
        fos_userbundle:
            id: fos_user.user_provider.username

    # Par-feu
    firewalls:
        dev:
            pattern:  ^/(_(profiler|wdt)|css|images|js)/
            security: false

        # Par-feu du Backoffice
        admin:
            pattern: ^/admin/
            form_login:
                provider: fos_userbundle
                csrf_provider: form.csrf_provider
                login_path: fos_admin_user_security_login
                check_path: fos_admin_user_security_check
                default_target_path: route_admin_home # A modifier avec le nom de votre route d'accueil pour le Backoffice
            logout:
                path: fos_admin_user_security_logout
                target: fos_admin_user_security_login
            anonymous: true

        # Par-feu du FrontOffice
        main:
            pattern: ^/
            form_login:
                provider: fos_userbundle
                csrf_provider: form.csrf_provider
                login_path: fos_user_security_login
                check_path: fos_user_security_check
            logout:
                path: fos_user_security_logout
            anonymous: true

    # Contrôle des accès : très important pour permettre la connexion au Front et au Back
    access_control:

        # Accès à autoriser pour la connexion au FrontOffice
        - { path: ^/[a-z][a-z]/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/[a-z][a-z]/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/[a-z][a-z]/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }

        # Accès à autoriser pour la connexion au BackOffice
        - { path: ^/admin/[a-z][a-z]/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        
        # Protection du Backoffice en sécurisant les liens admin
        - { path: /admin, role: ROLE_MODERATOR }

Remarques : Je sais que vous vous demandez ce qu'est : [a-z][a-z]. C'est tout simplement la gestion de la locale pour un site multilingue. J'utilise pour se faire le Bundle : JMSI18nRoutingBundle. Celui me permet de traduire mes URL et de gérer ma locale dans mes URL. Avec ma configuration actuelle j'obtiens des URL de type:

"domaine.com/fr/utilisateurs/voir/{username}"
"domaine.com/en/users/show/{username}"

Avec une petite particularité pour le Backoffice, un prefix admin :

"domaine.com/admin/fr/utilisateurs/voir/{username}"
"domaine.com/admin/en/users/show/{username}"

D'autre possibilité existe avec par exemple la gestion de différents hosts : fr.domaine.com, en.domaine.com, ... où il sera nécessaire de réadapter notre security.yml. Je vous laisse voir la doc du bundle si vous voulez en savoir plus .

 Attention, si vous utilisé un système similaire, il est très important de ne pas traduire les url de connexion sinon les "access_control" vont planter... Ou alors adaptez les, par exemple :

# Accès à autoriser pour la connexion au FrontOffice
- { path: ^/[a-z][a-z]/(login|connexion)$, role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/[a-z][a-z]/(register|enregistrer), role: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/[a-z][a-z]/(resetting|reinitialiser), role: IS_AUTHENTICATED_ANONYMOUSLY }

# Accès à autoriser pour la connexion au BackOffice
- { path: ^/admin/[a-z][a-z]/(login|connexion)$, role: IS_AUTHENTICATED_ANONYMOUSLY }

3) Une fois nos firewalls configurés, il nous faut surcharger l'action "renderLogin()" du controller "SecurityController.php" de FOSUserBundle afin de rediriger vers le bon template de connexion suivant la route de login utilisée, Back ou Front :

Acme/UserBundle/Controller/SecurityController.php

namespace Ceva\Bundle\UserBundle\Controller;

use Symfony\Component\HttpFoundation\RedirectResponse;
use FOS\UserBundle\Controller\SecurityController as BaseController;

// Surcharge de la classe FOS\UserBundle\Controller\SecurityController
class SecurityController extends BaseController {

    // Surcharge de l'action renderLogin()
    public function renderLogin(array $data) {
        $requestAttributes = $this->container->get('request')->attributes;

        /* 
         * Teste de la route de provenance
         * Si route Backoffice login : redirection vers le template de connexion de l'administration
         * Sinon si route FrontOffice login : redirection vers le template de connexion du Frontoffice (l'original de FOSUserBundle)
         */
        if ($requestAttributes->get('_route') == 'fos_admin_user_security_login') {
            $template = sprintf('AcmeAdminBundle:Security:login.html.twig');
        } else {
            $template = sprintf('FOSUserBundle:Security:login.html.twig');
        }

        return $this->container->get('templating')->renderResponse($template, $data);
    }

}

4) Pour terminer, il nous reste plus qu'à créer le template de connexion du Backoffice en oubliant pas de modifier l'action du formulaire pour la faire pointer vers la route de vérification de notre firewall "admin" :

{% extends "FOSUserBundle::layout.html.twig" %}

{% trans_default_domain 'FOSUserBundle' %}

{% block fos_user_content %}
{% if error %}
    <div>{{ error|trans }}</div>
{% endif %}

# Ne pas oublier de mofifier l'action pour la faire pointer sur le check du firewall admin
<form action="{{ path("fos_admin_user_security_check") }}" method="post">
    <input type="hidden" name="_csrf_token" value="{{ csrf_token }}" />

    <label for="username">{{ 'security.login.username'|trans }}</label>
    <input type="text" id="username" name="_username" value="{{ last_username }}" required="required" />

    <label for="password">{{ 'security.login.password'|trans }}</label>
    <input type="password" id="password" name="_password" required="required" />

    <input type="checkbox" id="remember_me" name="_remember_me" value="on" />
    <label for="remember_me">{{ 'security.login.remember_me'|trans }}</label>

    <input type="submit" id="_submit" name="_submit" value="{{ 'security.login.submit'|trans }}" />
</form>
{% endblock fos_user_content %}

C'est fini ! Si tout se passe bien, vous avez deux systèmes de connexion indépendants. Ainsi même logué en ROLE_SUPER_ADMIN sur le Front, si vous tenter d'accéder au Back avec domaine.com/admin(.*), vous aller être redirigé vers votre template de connexion d'administration où il vous faudra renseigner à nouveau vos identifiants pour pouvoir continuer. Vous pouvez aussi créer un second "provider" afin par exemple de séparer totalement vos utilisateurs Front et Back. Ce n'était pas ce que je recherchais, donc je ne l'ai pas fait, mais libre à vous d'aller plus loin.

Vous pouvez pratiquement refaire les mêmes manipulations pour obtenir un système de "resetting" coté Backoffice. Ce que je n'ai pas encore fait, mais ça ne serai tarder .

Voilà pour le petit tutoriel, il va sans doute être modifié un peu par la suite suivant vos remarques. J'ai essayé d'être clair, si quelque chose vous perturbe n'hésitez pas à demander.

En espérant vous être utile .

-
Edité par Aratyorr 8 avril 2014 à 14:52:28

post éclairant, merci

ps: tu n'aurais pas oublié de mettre csrf_provider: form.csrf_provider dans la partie admin de ton firewall?


Pas obligatoire le csrf, ça fonctionne sans, mais tu peux le rajouter .

EDIT : Je viens de la rajouter, c'est vrai que c'est plus propre

-
Edité par Aratyorr 8 avril 2014 à 12:50:29

le csrf n'est pas obligatoire à la soumission de ce formulaire parce que ce n'est qu'après que le serveur te donnera ton jeton identifiant(et donc c'est inutile tant que tu n'es pas identifié), j'ai bon?

tu n'as surchargé que le layout de connexion de la partie admin et pas celui du front?enfin, c'est ce que je comprend de ta surcharge du contrôleur

Alors pour le jeton CSRF, il n'est pas obligatoire car si tu ne déclare pas à ton firewall un fournisseur de jeton CSRF il ne contrôlera pas le jeton, donc au final il fonctionne. Cependant ton formulaire de login ne sera pas sécurisé contre les failles CSRF. C'est donc une faille de sécurité. C'est pourquoi il est recommandé de déclarer un fournisseur de jeton CSRF à ton firewall et d'afficher le jeton dans le template de ton formulaire de connexion afin de te protéger de cette faille. Après ton intervention j'ai donc rajouter la déclaration du fournisseur CSRF dans le firewall admin de mon tutoriel.

Petit rappel : Sur Symfony 2 tu n'es jamais non identifié, tu es toujours au minimum anonyme. Donc même déconnecté le serveur te fournit toujours un jeton CSRF ;).

J'en est surchargé aucun lol. J'ai surchargé l'action renderLogin() qui envoi à l'utilisateur le formulaire de connexion. J'ai juste rajouté un type de formulaire de connexion différent à envoyer à la place de celui de FOSUserBundle suivant la route login à afficher.

Ensuite tu peux surcharger le template de login de FOSUserBundle (Celui du FrontOffice), pour cela tu dois simplement créer un fichier "src/Acme/UserBundle/Resources/views/Security/login.html.twig" et Celui-ci remplacera automatiquement le formulaire de login de base de FOSUserBundle.

-
Edité par Aratyorr 8 avril 2014 à 14:56:38

Si ce tutoriel peut-être utile j'essayerai de prendre le temps d'écrire un petit cours un peu plus détaillé. Je suis surpris qu'un tel tutoriel n'existe pas vu l'utilité de ce système. Même surpris que FOSUserBundle ne gère pas le cas.

-
Edité par Aratyorr 8 avril 2014 à 15:01:05

Salut Aratyorr !

Merci beaucoup pour ce tuto. C'est exactement ce que je voulais faire ! Tu m'as économisé quelques heures et des cheveux.

Il ne me reste plus qu'a styliser ma page d'accueil pour qu'elle fasse peuuur.

Edit: Tu sais comment faire pour empêcher le préremplissage des champs du formulaire de login ? Quand le formulaire s'affiche pour aller sur le backoffice, les champs sont préremplies avec le pseudo et le mp, du coup il n'y a plus qu'a faire ok et on est dans le backoffice...

-
Edité par Esmedo 14 mars 2015 à 16:58:15

J'étais au bord du suicide, merci mille fois. Même après deux ans ce sujet est d'actualité, c'est fou !..

Big up à toi

P.S : un détail que moi je n'avais pas compris : dans la config de FosUser on ne peut spécifier qu'un seul firewall ! Or moi j'avais besoin d'utiliser le form_login pour l'admin mais aussi pour mon api côté front. Et la solution c'est simplement de spécifier un firewall qui regroupe les deux, autrement dit "main" avec le pattern : ^/  par exemple...

Bonjour,

Je suis sur Symfony 3.2 et j'ai l'erreur suivante :

You have requested a non-existent service "request". Did you mean one of these: "data_collector.request", "monolog.logger.request", "request_stack", "router.request_context", "validate_request_listener"?

Le service "request" a était remplacé ?

Bonjour Armnit,

Avez-vous trouver la solution à ce problème? J'ai le même.

Je vous remercie.

Armnit a écrit:

Bonjour,

Je suis sur Symfony 3.2 et j'ai l'erreur suivante :

You have requested a non-existent service "request". Did you mean one of these: "data_collector.request", "monolog.logger.request", "request_stack", "router.request_context", "validate_request_listener"?

Le service "request" a était remplacé ?

Bonjour, 

Oui, j'utilisais le service "request" qui est maintenant obsolète depuis symfony 3.0.

La solution ici :

https://stackoverflow.com/questions/41361267/how-can-i-fix-request-service-is-deprecated-in-symfony2-version-2-8

Bonjour,

Merci pour ta réponse, mais j'avais effectivement fini par identifier le problème. Oublié d'y poster ma réponse.

Bonjour,

j'ai suivi vos démarche j'ai eu une erreur 

You must configure the check path to be handled by the firewall using form_login in your security firewall configuration.

j'ai un probleme avec le firewall recruteur.

Le fichier security.yml:

    firewalls:
        # disables authentication for assets and the profiler, adapt it according to your needs
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false

        main:
            pattern: ^/
            form_login:
                  provider: fos_userbundle
                  csrf_token_generator: security.csrf.token_manager
                  login_path: fos_user_security_login
                  check_path: fos_user_security_check
                  remember_me: true
            logout:
                  path: fos_user_security_logout
            anonymous:    true
            remember_me:
                   secret: '%secret%'
            guard:
                authenticators:
                    - app.security.login_form_authenticator
        recruteur:
            pattern: ^/recruteur/
            form_login:
                  provider: fos_userbundle
                  csrf_token_generator: security.csrf.token_manager
                  login_path: fos_recruteur_user_security_login
                  check_path: fos_recruteur_user_security_check
                  remember_me: true
                  default_target_path: route_espace_recruteur
            anonymous: true
            logout:
                  path: fos_recruteur_user_security_logout
                  target: fos_recruteur_user_security_login
            remember_me:
                   secret: '%secret%'
            guard:
                authenticators:
                    - app.security.login_form_authenticator
    access_control:
            # Accès à autoriser pour la connexion au FrontOffice
            - { path: ^/[a-z][a-z]/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
            - { path: ^/[a-z][a-z]/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
            - { path: ^/[a-z][a-z]/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
            # Accès à autoriser pour la connexion au BackOffice
            - { path: ^/admin/[a-z][a-z]/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
            # Protection du Backoffice en sécurisant les liens admin
            - { path: /admin, role: ROLE_MODERATOR }

Bonjour,

j'ai suivi vos étapes et j'ai eu cette erreur quand j'ai essayé de me connecter avec le deuxième utilisateur :

You must configure the check path to be handled by the firewall using form_login in your security firewall configuration.