mai 9

Peanut : Semaine 4 – sfDoctrineGuardPlugin

Il c’est passé un peu de temps depuis le dernier article et je continue tranquillement à avancer au rythmefixé (au moins un lot de fonctionnalités par semaine) mais j’ai eu énormément de travail ces derniers temps et donc… Aucune nouvelle.

Semaine 3 – template, template, template

La semaine dernière a essentiellement servie à créer le layout du backend. Pas grand chose à dire à ce niveau, j’ai essayé de me faire un peu plaisir avec un peu de CSS3, un peu de jQuery et du xHTML (et oui, pas de HTML5 pour le backend). Je n’ai par contre pas encore pris le temps de valider les pages. Il peut donc y avoir quelques erreurs d’intégration. Le backoffice n’a également pas été testé sur la famille Internet Explorer mais je m’en occuperais dans quelques itérations au maximum car inutile de vous le cacher, mon prochain blog tournera bel et bien sur peanut (quitte à devoir évoluer avec).

Semaine 4 – spéciale sfDoctrineGuardPlugin

Comme je l’avais dis au début du projet, je comptais bien modifier sfDoctrineGuardPlugin. Lors de la création du projet, je suis parti sur la base du trunk de sfDoctrineGuardPlugin qui ajoute certaines fonctionnalités avec deux modules : sfGuardForgotPassword et sfGuardRegister permettant respectivement de récupérer son mot de passe et de se créer un compte.

Malheureusement, les process utilisés lors de ces étapes ne sont pas « corrects » dans le sens ou si effectivement ils fonctionnent, ils ne font pas forcément les choses correctement. Je me suis donc efforcé de modifier ces éléments afin de corriger un peu le tir, tout du moins à mon sens. Rassurez-vous, les modifications ne sont pas nombreuses mais en voici quelques unes.

sfGuardAuth

Possibilité via le fichier app.yml d’autoriser ou non la connection via le nom d’utilisateur et le mot de passe

sfGuardUser

Modification du fichier schema.yml afin qu’un utilisateur ne soit pas actif par défaut

sfGuardRegister

Modification de la route afin de pouvoir gérer le process d’inscription
Lors de la création de compte, un email est envoyé à l’utilisateur afin de confirmer la création du compte
Modification du process d’inscription qui va se charger de vérifier certains points importants avant d’activer le compte

sfGuardForgotPassword

L’email envoyé par défaut indique un délai de 24H pour valider son compte mais le code n’imposait pas de limite et n’enregistrait même pas la limite correctement
Ajout d’une tache permettant via cronjob de supprimer tous les utilisateurs n’ayant pas validé leur compte

De façon générale - Ajout de traductions (uniquement en français)

Parce qu’il faut tout de même le dire

Ce qui est actuellement en place est bien entendu perfectible. Le process d’inscription par exemple va générer une chaine sha1 basée sur le nom d’utilisateur, son adresse email et le csrf token de l’application et comme vous pouvez vous en douter… Il y a mieux (mais il y a aussi largement pire).

Pour moi, il faudrait créer une nouvelle table permettant de stocker les utlisateurs en cours d’inscription avec une clé unique en base de donnée afin de vraiment garantir la sécurité à ce niveau. L’autre option pourrait être de générer le sha1 sur la base du timestamp de création du compte qui pourrait ainsi (puisque stocké en bdd via created_at) servir de base un peu plus fiable. Autre solution, enregistrer l’utilisateur, récupérer l’objet utilisateur et générer quelque chose d’unique basé sur le salt par exemple.

Ceci dit je préfère attendre quelqu’uns de vos retours et mettre tout ça dans ma todolist pour un (éventuel et certains) refactoring dans le futur.

Autre chose, l’ensemble de ce travail a directement été fait dans le plugin sfDoctrineGuard car cela fais vraiment parti pour moi des fonctions à assurer au minimum et non à rajouter à la volée suivant les besoins de chaques projets (contrairement à la personnalisation des templates par exemple). Vous pouvez donc très bien surcharger ce qui est fait mais par défaut, une personne s’inscrit, reçoit un email de confirmation puis confirme son compte et cela tiens quand même plus la route qu’une inscription directe sans plus de vérification que ça.

Enfin, les tests unitaires ne sont pas complets et il faut vraiment que je m’y mette. Cela me dépasse encore un peu pour le moment. Je vois bien le principe mais je ne sais pas si c’est parce que j’ai l’habitude de chercher à faire tout de suite compliqué mais la… Je ne serais pas contre un petit cours à l’oral avec démo et questions connes en direct.

Ceci dit et si jamais j’arrive (ou nous arrivons via vos éventuelles contributions) à améliorer le plugin sfDoctrineGuard, j’aimerais le proposer afin qu’il soit intégré aux plugins (voir remplacer la version actuelle). Certaines conversations lues sur IRC me font dire que ce ne serait pas une mauvaise chose.

Petit détail d’importance, il faut que vous sachiez que mon anglais est encore moins bon que mon français à l’écrit en ce moment. Si jamais vous voulez modifier ça parce que… Hum… Okay mais bon il y a mieux, n’hésitez pas. Il faudrait également s’occuper de la traduction espagnole (puisqu’il y en a une pour le plugin) pour ne pas faire de malheureux mais la… Je vous laisse faire.

A quoi peut servir peanut actuellement ?

Si jamais vous vous posez la question, peanut peut vous servir (dans l’état actuel) à tout et à rien puisqu’il n’assure rien d’autre que la gestion de vos utilisateurs, groupes et permissions. Il est donc envisageable de faire n’importe quoi autour de ça : Réseau social, trombinoscope, intranet, extranet… Et j’en passe.

J’essaierai de vous donner ce genre d’exemples à chaque itération.

Le débat de la semaine

Le débat de la semaine porte sur la traduction i18n pour les setFlash(). Un gist a donc été créé et de la même façon que lors de la précédente question ouverte, je vous invite à l’enrichir via vos différentes méthodes afin de trouver les différentes façons de faire. Vous en trouverez actuellement trois, plus ou moins sexy mais qui fonctionnent toutes.

A venir

Le premier module du CMS permettant tout simplement de créer des « pages » (comprendre pages dynamiques peu modifiées du type CGU/CGV/…) pour votre site Internet.

Et pour finir

J’ai activé le système de donation sur le projet. A défaut d’aller directement dans mes poches, tout sera stocké sur un compte paypal dédié dans le but de m’offrir certaines formations dispensées par SensioLabs Trainings qui seraient à priori :

PHP niveau 1 : bases
PHP niveau 2 : POO
Symfony 1.4 + Doctrine
Symfony et REST
Doctrine

Bien entendu, cela pourra évoluer (je l’espère bien) avec ce projet puisque le but pour moi est de pratiquer encore et encore afin de m’améliorer jusqu’au moment où je pourrais trashtalk sur PHP .