Listing 13-2
Listing 13-3
Listing 13-4
Dans cette section, vous allez apprendre comment créer un formulaire de connexion basique qui continue d'utiliser les utilisateurs codés en dur que vous avez défini dans le fichier security.yml. Pour charger les utilisateurs de la base de données, lisez Comment charger les utilisateurs depuis la base de données (le fournisseur d'Entité). En lisant cet article et cette section, vous pouvez créer un système de connexion complet qui charge les utilisateurs dans la base de données.
Pour l'instant, vous avez vu comment protéger votre application derrière un pare-feu et ensuite comment protéger l'accès à certaines zones en utilisant les rôles. En utilisant l'authentification HTTP, vous pouvez sans effort profiter de la boite login/mot de passe offert par tous les navigateurs. Mais Symfony comprend plusieurs mécanismes d'authentification par défaut. Pour plus de détails sur chacun d'eux, référez-vous à la documentation de référence sur la configuration de la sécurité.
Dans cette section, vous allez améliorer le processus en autorisant l'utilisateur à s'authentifier via un formulaire de connexion traditionnel.
D'abord, activez le formulaire de connexion (« form login ») de votre pare-feu: 1 2 3 4 5 6 7 8 9 # app/config/security.yml security: firewalls: secured_area: pattern: ^/ anonymous: ~ form_login: login_path: /login check_path: /login_check
Si vous ne voulez pas personnaliser les valeurs de login_path ou check_path (les valeurs utilisées ici sont celles par défaut), vous pouvez raccourcir votre configuration :
1 form_login: ~
Maintenant, quand le système de sécurité initie le processus d'authentification, il va rediriger l'utilisateur au formulaire de connexion (/login by default). L'implémentation de ce formulaire de connexion est de toute évidence votre responsabilité. Tout d'abord, créez 2 routes : une qui affiche le formulaire de connexion (ici, /login) et une qui va prendre en charge la soumission du formulaire (ici, /login_check) : 1 2 3 4 5 6 # app/config/routing.yml login: pattern: /login
defaults: { _controller: AcmeSecurityBundle:Security:login } login_check:
pattern: /login_check
Vous n'avez pas à implémenter un contrôleur pour l'URL /login_check car le pare-feu va automatiquement intercepter et traiter tout formulaire soumis à cette URL.
Listing 13-5
Listing 13-6
New in version 2.1: Dans Symfony 2.1, vous devez avoir des routes configurées pour vos URLs login_path (ex /login), check_path (ex /login_check) et logout (ex /logout - voir Se déconnecter).
Veuillez noter que le nom de la route login n'est pas important. Ce qui importe est que l'URL de la route (login) corresponde à la valeur de login_path, car c'est là que le système de sécurité va rediriger les utilisateurs qui doivent se connecter.
Ensuite, créez un contrôleur qui va afficher le formulaire de connexion: 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/Acme/SecurityBundle/Controller/SecurityController.php; namespace Acme\SecurityBundle\Controller; use Symfony\Bundle\FrameworkBundle\Controller\Controller; use Symfony\Component\Security\Core\SecurityContext; class SecurityController extends Controller
{
public function loginAction() {
$request = $this->getRequest(); $session = $request->getSession(); // get the login error if there is one
if ($request->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) { $error = $request->attributes->get(SecurityContext::AUTHENTICATION_ERROR); } else {
$error = $session->get(SecurityContext::AUTHENTICATION_ERROR); $session->remove(SecurityContext::AUTHENTICATION_ERROR); }
return $this->render('AcmeSecurityBundle:Security:login.html.twig', array( // last username entered by the user
'last_username' => $session->get(SecurityContext::LAST_USERNAME),
'error' => $error, ));
} }
Ne vous laissez pas impressionner par le contrôleur. Comme vous allez le voir dans un moment, lorsque l'utilisateur soumet le formulaire, le système de sécurité prend en charge automatiquement le formulaire soumis. Si l'utilisateur venait à soumettre un login ou un mot de passe invalide, ce formulaire lit les erreurs de soumission du système de sécurité afin qu'elles soient ensuite affichées à l'utilisateur.
En d'autres termes, votre rôle est d'afficher le formulaire de connexion et toute erreur qui aurait pu survenir, mais c'est le système de sécurité lui-même qui prend en charge la validation du login et du mot de passe et qui authentifie l'utilisateur.
Il ne nous reste qu'à créer le template correspondant : 1 2 3 4 5 6 7 8 9 10 {# src/Acme/SecurityBundle/Resources/views/Security/login.html.twig #} {% if error %}
<div>{{ error.message }}</div> {% endif %}
<form action="{{ path('login_check') }}" method="post"> <label for="username">Login :</label>
<input type="text" id="username" name="_username" value="{{ last_username }}" /> <label for="password">Mot de passe :</label>
11 12 13 14 15 16 17 18 19 20
<input type="password" id="password" name="_password" /> {#
Si vous voulez contrôler l'URL vers laquelle l'utilisateur est redirigé en cas de succès
(plus de détails ci-dessous)
<input type="hidden" name="_target_path" value="/account" /> #}
<button type="submit">login</button> </form>
La variable error passée au template est une instance de AuthenticationException1. Elle peut contenir plus d'informations - et même des informations sensibles - à propos de l'échec de l'authentification, alors utilisez là judicieusement !
Le formulaire a très peu d'exigence. D'abord, en soumettant le formulaire à /login_check (via la route login_check), le système de sécurité va intercepter la soumission du formulaire et traiter le formulaire automatiquement. Ensuite, le système de sécurité s'attend à ce que les champs soumis soient nommés _username et _password (le nom de ces champs peut être configuré).
Et c'est tout ! Lorsque vous soumettez le formulaire, le système de sécurité va automatiquement vérifier son identité et va soit authentifier l'utilisateur, soit renvoyer l'utilisateur au formulaire de connexion, où les erreurs vont être affichées.
Récapitulons tout le processus :
1. L'utilisateur cherche à accéder une ressource qui est protégée;
2. Le pare-feu initie le processus d'authentification en redirigeant l'utilisateur au formulaire de connexion (/login);
3. La page /login affiche le formulaire de connexion en utilisant la route et le formulaire créés dans cet exemple.
4. L'utilisateur soumet le formulaire de connexion à /login_check;
5. Le système de sécurité intercepte la requête, vérifie les informations d'identification soumises par l'utilisateur, authentifie l'utilisateur si elles sont correctes et renvoie l'utilisateur au formulaire de connexion si elles ne le sont pas.
Par défaut, si les informations d'identification sont correctes, l'utilisateur va être redirigé à la page originale qu'il avait demandée (par exemple /admin/foo). Si l'utilisateur est allé directement au formulaire de connexion, il sera redirigé à la page d'accueil. Cela peut être entièrement configuré, en vous permettant, par exemple, de rediriger l'utilisateur vers une URL spécifique.
Pour plus de détails, et savoir comment personnaliser le processus de connexion par formulaire en général, veuillez vous reporter à Comment personnaliser votre formulaire de login.
Listing 13-7
Listing 13-8
Listing 13-9