Discussion :

[Mordri]

Rebonjour j'ai encore 2 autres questions, je fait des postes différents car elles n'ont rien en commun.

J'aimerai savoir comment créer un formulaire d'inscription sécurisé?

J'utilise sfDoctrineGuardPlugin et j'ai voulu àjouter des champs donc j'ai fait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
User:
  inheritance:
    type:    simple
    extends: sfGuardUser
  columns:
    phone: { type: integer, notnull: true}
    ...

Si je génère un module CRUD, le mot de passe est affiché en clair dans le formulaire car c'est un champ texte par défaut, je peux donc modifier le widget mais si je modifie le widget par password symfony encode t'il l'envoie pour ne pas passer en clair le mdp? Et comment créer une vérification de mdp (donc écrire deux fois le mdp)

Sinon dans le backend il y a un module user mais je ne sais pas le personnaliser, (je pourrais l'utiliser pour l'inscription en retirant les champs de droits, et en ajoutant mes nouveau champ)

app/backend/config/setting.yml:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

enabled_modules: [default, sfGuardAuth, sfGuardUser]

[Michel Rotta]

Il y a un plugin qui rajoute ces fonctionnalités à sfGuard. Regarde dans la salle des plugins, le sujet épinglé.

[Mordri]

Effectivement sfForkedDoctrineApply est vraiment bien, par contre j'ai un petit soucis dans les tables, sf_guard_user_profile a un champ firstname et lastname, et dans sf_guard_user il y a aussi first_name et last_name, sauf que quand je créée ou modifie un utilisateur avec le formulaire de sfForked, les champs dans sf_guard_user_profile sont mis à jour mais pas ceux dans sf_guard_user. Le problème est que mes tables sont lié à sf_guard_user donc le nom est prénom affiché ne sont pas bons :/

[Michel Rotta]

Vérifie les versions des deux plugins.

[Mordri]

question toute bête mais on vérifie comment leur version :p ?


sinon normalement j'ai télécharger les dernières versions, 5.0.0 pour sfDoctrineGuard et 1.5.6 pour sfForked

edit: j'ai réinstaller les dernières versions pour être sur, j'ai toujours le même problème, j'ai changé mes liaisons de sfGuardUser par sfGuardUserProfile et tout marche nickel, sauf pour le module sfGuardUser auto généré grâce au setting.yml

[Michel Rotta]

Bonne question... D'autant que le fichier version de sfDoctrineGuardPlugin indique ... 1.0.4 ! (pour la version 5)

Il n'y a, hélas, pas de normalisation des numérotations des versions pour les plugins. Il faut ce référer au nom du zip téléchargé.

Tu as les dernières version (bonne nouvelles).

Lors de l'enregistrement (doSave sur sfApplyApplyForm) les nom, prénom et email du user sfFDAP sont recopié dans l'objet sfUser.

Le formulaire de modification, lui, travail sur les données de sfGuard.

Je n'ai jamais trop compris l'intérêt de cette double information, mais, en principe, et si tu ne chipote pas trop, cela doit fonctionner (jamais eu de messages la dessus).

[Mordri]

j'ai fait un edit de mon précédent message en même temps que le tien ^^', j'essaierai de voir après manger mon petit soucis

[PeytaWodka]

C'est un soucis classique avec ces deux plugins. Seule solution que j'ai trouvé pour garder les champs à jour, c'est surchargé la méthode save des objets comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
    public function save(Doctrine_Connection $conn = null)
    {
        $this->getUser()->setFirstName($this->firstname);
        $this->getUser()->setLastName($this->lastname);
 
        return parent::save($conn);
    }

[Mordri]

ok, merci beaucoup

c'est dommage qu'il faut bidouiller les methodes saves mais bon ça va pas me tuer :p

[Michel Rotta]

En fait, il faudrait ne se servir des champs nom et prénom de sfFADP uniquement pour la création et de ceux de sfGuard pour le reste. D'autant que les noms des champs entre les deux tables sont incompatibles.

[Mordri]

En mettant mes tables en relation avec "l'utilisateur sfFDAP" et en modifiant la méthode save de PeytaWodka ça marche pas mal, y'a juste pas la possibilité de changer le nom par le formulaire de gestion de sfUser (enfin celui où on ajoute les droits) mais c'est pas vraiment utilse à l'admin de changer les noms. Sachant que dans "mes préferences" de sfFDAP l'utilisateur peut les modifier sans soucis.

[PeytaWodka]

Si tu veux pouvoir modifier les nom prénom à partir du User, il suffit de surcharger la méthode save de sfGuardUser aussi comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public function save(Doctrine_Connection $conn = null)
{
    $this->getProfile()->setFirstname($this->first_name);
    $this->getProfile()->setLastname($this->last_name);
 
    return parent::save($conn);
}

(Non testé.)

[Michel Rotta]

Je n'ai pas créé de site avec sfGuard et sfFDAP depuis les mises à jour, mes deux dernières création ne prennent que sfGuard en compte. Je manque donc d'expérience sur la mise en œuvre de sfFDAP dans "la vraie vie".

Je me pose malgré tout une question, partant du présupposé que les développeur de sfFADP sont des gents intelligent, pourquoi ont-il géré ce type de schéma avec un "doublon" sur le nom et le prénom ? N'y aurait-il pas une raison fonctionnel à ce doublon ?

[PeytaWodka]

C'est ce que je me suis dit aussi mais j'ai trouvé aucune raison pour le moment. A mon avis, on doit laisser les champs first_name et last_name de sfGuardUser a NULL mais dans ce cas là, on tombe sur un problème avec la méthode __toString() de sfGuardUser qui ne fonctionne plus ou retourne seulement le username.

[Michel Rotta]

Il est évident que les champs de sfGuard doivent être renseigné, ils le sont à la création de l'utilisateur. La question est, doit-on maintenir les champs de sfFDAT ?

Il me semble que cette table est plutôt une sorte de sas d'intégration, où les personnes créée mais non validées par email attendent. Une fois le compte validé, il passe dans le sfGuard et l'enregistrement dans sfFDAP devient caduc.

Mais ce n'est qu'un avis et il ne s'appuie sur aucune expérience.

[Mordri]

Bah le problème c'est que si tu souhaite modifier les nouveaux champs tu doit passer par le formulaire de sfFDAP, donc je comprend pas pourquoi la mise à jour du nom et du prénom ne se fait pas automatiquement.

[Michel Rotta]

Ceci confirme ce que je pense. La table de sfFDAP ne sert qu'à la création, pas à la modification ni la maintenance.

Ce qui est, hélas, en opposition avec le readme de sfFDAP qui conseil de modifier la table pour y stocker les propriétés supplémentaires de l'utilisateur

Il faut vraiment que je prenne une journée pour démonter ce système.