Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Installer et configurer FOSUserBundle sous Symfony 3

Par Sylvain IGLESIAS Publié le 06/10/2017 à 18:58:14 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

Introduction

Les sites web aujourd’hui disposent de fonctionnalités de base, qui se ressemblent sur chacun d’entre eux. Parmi elles, la connexion et l’inscription d’utilisateur, qui est présentent sur tous (presque) les sites webs. Peu importe le langage utilisé pour coder le site, c’est une fonctionnalité phare.

Symfony, framework orienté PHP, est riche de bundles développés par des utilisateurs, qui ont pour but d’améliorer le développement de tous.

Parmi eux, il y en a un qui va nous intéresser pour cet article: FOSUserBundle. Il va gérer lui-même la connexion et l’inscription, c’est-à-dire qu’il va proposer un formulaire (de base), mais aussi persister les données de l’utilisateur en base, tout ça de manière sécurisée.

Pré-requis et installation

Prérequis

Tout d’abord, puisqu’il s’agit d’un Bundle Symfony, il vous faudra donc Symfony d’installer. Petite piqûre de rappel :

Allez sur le site officiel de Symfony, et télécharger la version qui correspond à votre OS : https://symfony.com/download. Il vous suffira ensuite d’éxecuter la commande suivante, pour chaque nouveau projet :

$ symfony new <nomduprojet>

Il existe d’autres moyens bien sûrs d’installer Symfony, il est bien de les connaitre aussi. Comme ce n’est pas le but de cet article, une petite recherche sur Google vous permettra de les savoir, et ainsi de l’installer d’une manière différente.

Après installation, vous devriez avoir un projet ayant cette structure :

Installation de FOSUserBundle

Passons maintenant à l’installation du bundle :

Il existe deux moyens d’installer le FOSUserBundle. Dans tous les cas, il nous faut récupérer les sources et les installer dans le dossier vendor (c’est ici que s’installeront toutes les ressources externes au projet, dont les bundles).

En clonant le dépôt Git

Executez la commande suivante :

$ git clone https://github.com/FriendsOfSymfony/FOSUserBundle.git vendor/bundles/FOS/UserBundle

Via Composer

Executez la commande suivante :

$ composer require friendsofsymfony/user-bundle "~2.0"

Allez maintenant dans le dossier vendor vérifier que FOSUserBundle est bien installé :

Vous le voyez, il est bien présent dans votre projet, et celui-ci dispose de nombreux dossier. Allez dans le dossier Controller par exemple, vous voyez que celui contient plusieurs Controller, qui ont chacun une fonctionnalité bien à part : l’enregistrement, le profil, allant même jusqu’au changement de mot passe.

N’hésitez pas à regarder tous les dossiers, les explorer essayer de comprendre certaines choses. La curiosité amène les connaissances.

Une fois FOSUserBundle ajouté aux vendors, il nous faut l'activer dans le Kernel. Rendez-vous dans le dossier app/ , puis le fichier AppKernel. Ouvrez donc le fichier.

C’est dans ce fichier là que vous allez déclarer tous vos bundles installés (pas seulement FOSUserBundle), afin que vous puissiez les utiliser dans l’ensemble de votre projet. Ajoutez-y la ligne suivante :

Configuration de FOSUserBundle

Il nous faut maintenant configurer le bundle. Pour cela, allez dans le fichier app/config/config.yml, et ajoutez-y ce qui suit :

Nous avons mis comme user_class l’entité User, si pour vous elle n’existe pas encore, il faut la créer.

Pour cela, allez dans src/<votreBundle>, par défaut, il y a AppBundle qui existe, pour cet article, c’est celui que je vais utiliser. Il vous est tout à fait possible de créer vous-même votre bundle grâce à la commande :

$ php bin/console generate :bundle, puis de renseigner le nom.

Les entités se trouvent dans le dossier Entity du bundle, s’il n’existe pas, créez le (clic droit>New>Directory, puis renseigné Entity), puis créez un fichier User.php. Nous allons seulement renseigner un id, et un constructeur pour cet objet pour l’instant, libre à vous de rajouter des champs.

Voici ce que cela devrait donner :

Explications : nous avons juste hérité à la classe User le bundle FOSUserBundle grâce à « extends ».

Nous avons nommé la table « fos_user », et créée une propriété id que type AUTOINCREMENT.

Il existe une méthode plus simple pour générer une entité en une ligne de commande, et qui va vous mettre automatiquement les annotations correspondantes :

$ php bin/console doctrine :generate :entity

On renseigne le nom que l’on veut, donc pour nous AppBundle :User.

Il nous demande ensuite le format dans lequel nous souhaitons configuré notre entité. Choisissez celle que vous préférez, pour moi ce sera annotation, qui est sélectionné par défaut.

Il vous dit également qu’une clé primaire nommé id est générée automatiquement, c’est ce que l’on veut.

Libre à vous de rajouter des champs, sinon, faites Entrer.

Votre entité est maintenant créée !

Allez dans votre entité, changez le nom de la table si vous le souhaitez, mais surtout rajoutez le constructeur vu plus haut, ainsi que le extends et le use correspondant au FOSUserBundle, et mettez l’id en protected !

Cette commande de génération d’entité est pratique lorsque nous avons un object avec beaucoup de paramètre à générer, cela évite de tout se taper à la main, ainsi que les getters/setters. Dans notre cas, ça n’est pas forcément évident, mais il est bon de le savoir si vous ne le saviez pas.

Le bundle est désormais prêt à l’emploi, nous pouvons maintenant mettre notre base de données à jour.

Petit rappel : afin de la mettre à jour, il faut qu’elle soit au préalable créé. Pour cela, il faut modifier quelques paramètres : allez dans le fichiers app/config/parameters.yml.

Vous avez ici, tous les paramètres de connexion à votre base de données.

Modifiez le nécessaire pour vous, le nom de la base, le user, le mot de passe.

Une fois fait, créez la database. Pour cela, une seule commande doctrine à utiliser :

$ php bin/console doctrine:database:create

Notre bundle est désormais operationnel, nous pouvons mettre à jour notre base de données grâce à la commande :

$ php bin/console doctrine:schema:update –force

Voilà, votre base ainsi que votre table sont créées ! Allez donc vérifier que tout ça !

Regardez donc votre table user, elle contient douze champs qui ont été générés automatiquement.

On peut y voir que celle-ci comprend le username, l’email, le password qui sera crypté, mais aussi un token qui va permettre de gérer plus de sécurité dans tout ça.

Notre entité, elle, n’a pas été modifié niveau code, alors qu’il y a de nombreux nouveaux champs. Pourquoi ?

Tout simplement car dans le constructeur, nous faisons hériter le constructeur parent, c’est-à-dire celui du FOSUserBundle. Allez donc voir ce qu’il y a dedans (ctrl + clic gauche sur parent ::__construct).

On voit qu’il y a dedans toutes les champs de la base, avec leur getters et leur setters. Pratique non ?

Notre entité est donc opérationnelle !

Afin de la tester, nous allons générer le formulaire associé à celle-ci. Pour cela, exécutez la commande suivante :

$ php bin/console doctrine:generate:form AppBundle:User

Un nouveau dossier Form s’est créé, il contient un fichier .php nommé UserType.php

Il vous est evidemment possible de créer ce fichier à la main dans un dossier Form comme ci-dessus. Veuillez cependant veillez à respecter la notation : <nomentité>Type.php.

Afin de vérifier la bonne installation du bundle, ainsi que de voir tout ce qu’il est possible de faire avec celui-ci, exécutez la commande $ php bin/console

Vous avez ici, la liste des actions possible.

Routing, actions et affichage des formulaires

Nous avons notre formulaire, c’est très bien. Essayez donc d’accéder à la page localhost :8000/register, afin d’avoir le formulaire généré juste avant.

Nous avons une belle erreur.

En effet, nous n’avons pas de route configurée pour la page demandée, pour aucune des pages du formulaire généré d’ailleurs. Nous allons donc importer toutes les routes du bundle :

Allez dans le fichier app/config/routing.yml, et rajoutez donc la ligne suivante :

fos_user:

resource: "@FOSUserBundle/Resources/config/routing/all.xml"

Afin de bien comprendre ce que nous avons fait, allez dans le dossier vendor/friendsofsymfony/Resources/config/routing/, puis ouvrez le fichier all.xml.

Vous voyez que vous avez un ensemble de routes configurées en xml.

Retournez donc sur la page /register, et miracle, le formulaire s’affiche !

Créez un utilisateur, vous verrez que tout fonctionne.

Allez jetez un petit coup d’œil en base, votre utilisateur est bien présent !

Vous pouvez essayer remplir ce formulaire. Laissez un champ vide par exemple, ou ne renseignez pas les même mot de passe.

Vous voyez que Symfony gère aussi les erreurs. Et cela, sans que nous faisions la moindre ligne de code de notre côté.

Vous pouvez également accéder à la liste des routes générer par le bundle grâce à la commande suivante :

$ php bin/console debug:router

Cette commande est assez pratique en tant normal, mais surtout en debug. Vous avez, en plus des routes, les méthodes associées (GET, POST) afin de vous donner une idée. Elle regroupe également toutes les routes que vous auriez déjà créées au préalable.

Gestion des droits d'accès pour les utilisateurs

Tout est désormais fonctionnel. Seulement, tout le monde a accès à nos pages. Nous allons donc mettre le formulaire de login fonctionnel, ainsi, ceux qui auront accès à notre contenu doivent être enregistré et connectés.

Il nous faut donc restreindre l’accès à nos pages. Cela se passe dans le fichier de configuration app/config/config.yml.

Recopiez le fichier ci-dessous, afin d’avoir une sécurité similaire.

Explications :

On ajoute de la hierarchy de role (role_hierarchy) avec deux rôles ayant pour nom « ROLE_ADMIN » et « ROLE_SUPER_ADMIN », et ayant respectivement les droits « ROLE_USER », et « ROLE_ADMIN ».

Le "ROLE_USER sera automatique, quelqu’un d’authentifier aura directement ce rôle-là.

La section encoders permet de crypter le mot de passe.

Le provider, nommé ici fos_userbundle, va nous permettre de générer les clés.

Dans la section access_control, on spécifie les routes /login, /register et /resetting comme étant accessible par tous, mais, toutes les routes préfixées par /admin/ nécessiteront le rôle ROLE_ADMIN.

Il vous suffira donc, avec cette configuration, de préfixer les routes à protéger par /admin/ et le mécanisme de sécurité se mettra en œuvre.

Vous pouvez désormais gérer au cas par cas les espaces sécurisés simplement grâce à leurs routes !

Nous allons tester tout ça. Pour se faire, créez un dossier, et deux vues dans app/Ressources/views/. Nommez-les comme vous voulez.

J’ai ici crée un dossier contenant une vue qui sera accessible par tout les utilisateurs connectés, et une vue qui sera accessible seulement par les utilisateurs ayant le rôle admin.

Rendez-vous maintenant dans le Controller( src/AppBundle/Controller/VotreController), et ajoutez des fonctions qui vont uniquement faire un rendu de vos vues, et n’oubliez surtout pas les routes !

Pour l’exemple, j’ai utilisé le Controller créé par défaut. J’ai créé deux rendu :

  • L’un pour la route /user/test, qui va tester le ROLE_USER.

  • L’un pour la route /admin/test, qui va tester le ROLE_ADMIN.

Tester le ROLE_USER

Ajoutez la ligne suivante dans le security.yml.

- { path: ^/user/, role: ROLE_USER }

Cette ligne signifie que toute url commençant par /user/ nécessitera le ROLE_USER, il faudra donc être connecté.

Allez donc sur /user/test.

Nous ne sommes pas connecté, nous sommes donc automatiquement redirigé sur le formulaire de connexion.

Connectez-vous avec l’utilisateur que vous avez au préalable créez avant, sinon créez en un. (/register).

Et voilà, nous avons bien accès à la page.

Tester le ROLE_USER

Essayez maintenant de vous rendre sur la page /admin/test. Vous avez une belle erreur vous disant que vous n’avez pas accès à cette page.

Et cela est normal, vous avez un ROLE_USER, et tentez d’accédez à une page uniquement accessible par les utilisateurs ayant le ROLE_ADMIN.

Afin de tester le bon fonctionnement, exécutez la commande suivante :

$ php bin/console fos:user:promote <votrenomutilisateur> ROLE_ADMIN

Vous avez promu votre utilisateur, et lui avez donné le ROLE_ADMIN.

Déconnectez vous et reconnectez vous, vous devriez avoir accès à la page demandée.

Si vous avez toujours pas d’accès à la page, essayez de vider le cache, et essayez de vous y rendre à nouveau.

Pour vider le cache : $ php bin/console cache:clear

Autre manière de faire

Il existe cependant une autre manière d’instaurer cette sécurité d’accès à nos pages, et il peut être judicieux de la connaître.

En effet, rappelez-vous, nous avons configuré l’accès de nos pages dans le fichier app/config/security.yml.

- { path: ^/admin/, role: ROLE_ADMIN }

- { path: ^/user/, role: ROLE_USER }

Mais il vous est également possible de restreindre l’accès à vos pages directement dans les actions du Controller. Il vous suffit simplement de supprimer (ou de commenter) les deux lignes écrites plus haut, de vous rendre dans votre Controller, et pour chaques actions, y ajouter les lignes suivantes :

Retournez sur le site, déconnectez-vous, et reconnectez-vous. Il n’y a rien qui change ! Vous avez accès à vos pages, exactement comme avant.

L’avantage de gérer l’accès aux pages directement dans le Controller, vous permet de savoir directement par qui est réalisable l’action que vous avez demandé. Et c’est plutôt pratique.

Dernière chose à savoir, un utilisateur disposant du ROLE_ADMIN, a également accès à toutes les pages n’autorisant que les ROLE_USER, chose qui est plutôt logique. Ce n’est pas une raison pour donner ce rôle à tout le monde !

Maintenant, libre à vous de choisir la façon dont vous préférez sécuriser vos pages, soit dans un fichier à part, soit directement dans l’action.

Récupérer l'objet Utilisateur

A partir du moment où un utilisateur est connecté au site, vous y avez accès.

Comment cela est-il possible ? Car celui est stocké en session. A partir de là, vous pouvez récupérer ses informations, et les utiliser dans les templates, ou encore votre Controller dans les actions.

Utiliser l'utilisateur connecté dans un template

On peut penser que cela est compliqué, mais en réalité, c’est très simple !

Vous avez accès à l’utilisateur connecté grâce à la méthode {{ app.user }}. Cette méthode va récupérer un objet utilisateur, et cet objet utilisateur va contenir toutes les informations de notre utilisateur connecté.

Pour accéder à ses informations, rien de plus simple, il vous suffira de rajouter un « . », et de récupérer la propriété que vous souhaitez. Pour récupérer son nom par exemple, vous écririez {{ app.user.username }}.

Allez voir le résultat, vous avez bien le nom de votre utilisateur qui est rajouté.

Dans mon exemple ci-dessus, nous arriverons tout le temps à accéder à notre utilisateur, car la page que j’ai utilisée n’est accessible que par les utilisateurs connectés. Mais imaginons que cette page soit accessible par tous, qu’est ce que le template va afficher à la place du pseudo si c’est un utilisateur anonyme qui accède à ma page ?

En effet, nous aurons une erreur nous disons qu’il nous ne pouvons pas accéder à la propriété username de notre objet user.

Pour contrer cela, il suffit simplement de faire une condition : si il y a un utilisateur, on affiche le nom.

Vous pouvez également contrôler si un utilisateur à un rôle pour afficher du contenu. Pour cela, il existe la méthode dans l’objet user « hasRole », dans laquelle vous préciserez le rôle que vous souhaitez.

Voici un exemple d’utilisation :

Seules les personnes ayant le ROLE_ADMIN, pourront voir ce message.

Utiliser l'utilisateur connecté dans le Controller

Manipuler notre utilisateur dans les templates se fait très facilement, il serait dommage que ce ne soit pas le cas également dans notre Controller.

Vous allez pouvoir récupérer votre utilisateur grâce à la méthode $this->getUser().

Vous avez, bien évidemment, accès à toutes ses propriétés, ainsi qu’à toutes ses méthodes.

Supposons que je veuille modifier l’email de mon utilisateur, je veux que ce soit « [email protected] », dès qu’il se rend sur la page « /admin/test », afin que seul les admins changent leur email, rien de plus simple, allez dans le Controller :

La méthode persist() permet d’enregistrer localement le changement, mais c’est seulement lors du flush() que les données vont être modifiées en base.

En voilà la preuve :

Envoyer un email de confirmation lorsqu'un utilisateur s'inscrit

Beaucoup de développeurs PHP galéré à l’époque afin de créer une méthode d’envoi d’email à l’inscription, et qui marché une fois sur deux. FOSUserBundle lui, dispose de cette fonctionnalité. Alors pourquoi s’embêter à la développer ?

En effet, il existe une fonctionnalité toute prête permettant cet envoi d'email et validation de compte au-to-ma-tique. Cependant, celle-ci est désactivée par défaut. Pour l'activer, rien de plus simple, rendez-vous dans le fichier app/config/config.yml :

Rajoutez les lignes suivantes :

Explications : On utilise le service d’envoi de mail HTML, qui s’appelle « fos_user.mailer.twig_swift ».

On dit que pour l’enregistrement (registration), on active ce service. On précise l’email de l’expéditeur et son nom. Enfin, on dit quel template utilisé pour cette fonction d’envoi d’email, ici nous allons utiliser celui générer par FOSUserBundle. Un peu plus loin, nous verrons comment personnaliser notre email.

Nous devons renseigner de nouveaux paramètres afin de pouvoir envoyer des emails, allez donc dans parameters.yml.

La configuration ci-dessus est utilisée pour envoyer des mails via gmail. Il vous donc un compte gmail. Il est possible d’utiliser d’autres services messageries, à vous de rechercher sur internet comment les configurer.

Donc nous avons renseigné de nouveaux paramètres pour le service mailer, très bien, renseignons les dès à présent auprès de swift_mailer, retournez donc dans le fichier config.yml et rajoutez les champs suivants :

Chaque champ est relié avec un paramètre renseigné dans le fichier parameters.yml.

Votre service de messagerie est maintenant prêt à l’emploie !

Symfony dispose d’une commande permettant de tester l’envoie de mail, il s’agit de :

$ php bin/console swiftmailer:email:send

Executez cette commande. Un formulaire vous demande quel est l’expéditeur, le destinataire, le sujet et l’objet du mail, remplissez par ce que vous souhaitez.

Il est possible que vous receviez un email de gmail vous disant qu’une application externe a essayé de se connecter via votre compte. Vous devrez donc l’autoriser.

Si tout se passe bien, vous avez reçu un email, votre service est donc bien opérationnel !

On va le tester en direct alors, allez sur la page /register, et inscrivez-vous.

Vous devriez avoir un message comme quoi l’email a bien été envoyé.

Allez dans votre boite mail, un message de confirmation d’inscription devrait s’y trouver !

Et voilà, vous avez configuré un email d’inscription en quelques lignes.

Je vous l’ai dit plus haut, il vous est possible de créer votre propre modèle d’email. Pour cela, créer un template dans app/Resources/views/email/registration.email.twig.

Il ne nous reste plus ensuite qu'à définir le template que nous souhaitons utiliser pour l'envoi d'email :

N’oubliez pas de changer le template utilisé par le service dans le fichier config.yml.

Et voilà, vous recevez bien votre nouvel email personnalisé, à vous de le créer comme vous le souhaiter.

Quelques commandes utiles

Vous le savez, et on en a déjà vu quelques-unes, FOSUserBundle est fournie avec de nombreuses petites commandes, qui vont vous permettre de gérer vos utilisateurs plus facilement, sans avoir à créer de formulaire, etc…

Petit rappel, vous avez accès à la liste des commandes en utilisant la commande $ php bin/console, et cherchant la partit fos.

Création/activation/désactivation d'utilisateur

Pour créer un utilisateur :

$ php bin/console fos:user:create <nomutilisateur> <email> <motdepasse>

Pour activer un utilisateur :

$ php bin/console fos:user:activate <nomutilisateur>

Pour désactiver un utilisateur :

$ php bin/console fos:user:deactivate <nomutilisateur>

Gestion des rôles

Mettre le ROLE_ADMIN :

$ php bin/console fos:user:promote <nomutilisateur> ROLE_ADMIN

Enlever le ROLE_ADMIN :

$ php bin/console fos:user:demote <nomutilisateur> ROLE_ADMIN

Changer le mot de passe

$ php bin/console fos:user:change-password <nomutilisateur> nouveaumotdepasse

Erreurs courantes

L’installation d’un bundle n’est pas sans risque. Il est rare que tout marche du premier coup. Parfois on oublie de configurer un champ, des fois nous faisons une faute d’orthographe dans l’un de nos paramètres, cette section regroupe les erreurs récurrentes, et va vous montrer comment les corriger.

Problème :

The child node "user_class" at path "fos_user" must be configured. The child node "db_driver" at path "fos_user" must be configured. The child node "firewall_name" at path "fos_user" must be configured, . The child node "from_email" at path "fos_user" must be configured. . The child node "firewall_name" must be an array.

Solution :

Vous n'avez pas configuré l'un des éléments nécessaire au bon fonctionnement de FOSUserBundle, tout se passe dans le fichier app/config/config.yml:

Vous devez avoir au minimum, le db_driver, le firewall_name, la user_class et le from_email de configuré en Symfony 3, sinon vous aurez ces erreurs.

Attention, la partie from_email est un tableau ! Veillez à bien avoir les deux champs address et sender_name. Pour le firewall_name, veillez à bien renseigné celui renseigner dans le fihgcier security.yml, généralement, c’est main que l’on utilise. Enfin pour la user_class, il s’agit évidemment de la classe User qui va hériter du Bundle.

Problème :

ErrorException: Warning: class_parents(): Class MyApp\Entity\User does not exist and could not be loaded in */vendor/doctrine/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php line 223

Solution :

Vous avez mal configuré votre user_class dans app/config/config.yml. Vérifiez que votre namespace est bon, que votre classe se situe bien là ou vous l'avez définie.

Problème :

Mes labels dans les formulaires générés par le Bundle ne sont pas beaux. Ils sont de la forme form.email, form.username, etc.. Comment traduire tout ça ?

Solution :

Sur quelques screens, vous pouvez voir que j’ai également cet affichage, mais au bout d’un moment, je ne les ai plus car j’ai corrigé le problème. Comment ?

En allant dans le fichier app/config/config.yml, dé-commentez la ligne suivante :

translator: { fallbacks: ['%locale%'] }, et juste au dessus, dans la valeur locale, par défaut vous avez en, remplacez là par fr.

Problème :

J’ai une erreur lorsque je test l’envoie d’email via la commande $ php bin/console swiftmailer:email:send

Exception occurred while flushing email queue: Failed to authenticate on SMTP server with username "XXXXXXXXXX" using 1 possible authenticators [] [].

Solution

Veillez à bien renseigner vos paramètres dans le fichier parameters.yml, vérifiez le mailer_password, votre mailer_user, votre host… Si vous utilisez l’host proposé par gmail, mettez les paramètres comme suit.

Le mailer_transport en smtp, le mailer_encryption en ssl, et le mailer_auth_mode en login, sinon cela ne fonctionnera pas.

Faite bien la relation ensuite avec le services swiftmailer dans config.yml. Chaque paramètres renseignés dans le fichier parameters.yml doit être mappé dans la configuration de swiftmailer.

Problème :

Lorsque je modifie les infos d’un utilisateur dans mon Controller, elles ne persistent pas en base.

Solution

N’hésitez pas à debugger dans ces cas-là. Par exemple, faîtes un var_dump($this->getUser()); et voyez si vous récupérez votre utilisateur.

Vous devriez avoir un tas de données, votre utilisateur est donc bien existant. Utilisez bien les setters mis à votre disposition. Mais ça n’est pas tout !

Pour enregistrer des données en base, et ça peu importe ce que vous souhaitez enregistrer (un utilisateur, une autre entité, etc), il faut la persister.

Pour cela, il faut récupérer l’Entity Manager de la manière suivante :

$em = $this->getDoctrine()->getManager();

C’est lui qui va vous permettre d’effectuer des actions avec la base de données. Après ça, il faut persister les modifications de la manière suivante :

$em->persist(votreobjet);

Cela veut dire que cet objet et maintenant gérer par Doctrine, aucune requête SQL n’est encore effectuée.

Pour enregistrer ces données en base, il suffit de faire ainsi :

$em->flush();

Vous devriez avoir quelque chose de ce style :

Conclusion

FOSUserBundle est très puissant. Il vous permet de gérer des utilisateurs très rapidement, ainsi que les formulaires associés, et le tout sécurisé.

Il existe de nombreux Bundle mis à disposition de tous, il en existe aussi d’autre pour la gestion d’utilisateur ; mais celui-là est le plus utilisé, et vous trouverez de nombreuses de solutions si vous avez des problèmes, grâce à une forte communauté.

Le projet que j’ai créé afin de faire cet article se trouve à l’adresse suivante : https://github.com/Checkspear/TutoFOSUserBundle.

N’hésitez pas à récupérer les sources, à analyser le code, pour comprendre comment fonctionne ce Bundle. Il n’y a rien de compliqué, au départ cela peut s’avérer ne pas être facile, mais au final vous vous y retrouverez et y prendrais même goût.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels