Version imprimable
Non pas de mot de passe aléatoire, le client pas ne souhaite pas cela.
Les méthode setpassword() et getpassword() décrite ne fonctionne pas chez moi :
si on te touche pas au champs mot de passe , celui ci est sauvegardé avec une chaine vide qui est ensuite chiffré en sha1 avant d' être stocké en base.
résultat: on peut peux plus se logguer ni avec le dernier mot de passe ni même avec un mot de passe vide. Bref la cata !
Mais la chaine vide devrait justement être bloquée par :Si ce n'est pas le cas c'est :Code:if ( strlen( $pass ) > 0 )
- soit tu ne passes pas par le setter modifier (simple a vérifier)
- soit la condition retourne vrai, donc la chaine n'est pas vide, donc il faut savoir ce qu'elle contiend (print_r) et adapter le test.
Ceci ne remet pas en cause la structure de la modification, juste la validité du test.
J' ai bien tenté un ..
Comme je suis dans un template auto généré.. je ne vois rien. Le champs password est vide dans le formulaire edit, mais pourtant il est modifié en base.Code:
2
3
4
5
6
7
8
9
10
Ok , le mot de passe n' est pas modifié par contre il n' est plus chiffré en base si le modifie.
Résultat: on ne plus se loguer.
Autant pour moi, ils ont réécris le code entre sfGuard 4 et la version 5 actuellement proposée.
En fait, la nouvelle méthode vérifie qu'il y a bien un mot de passe envoyé (non null et > 0 caractères pour la chaine), si ces conditions ne sont pas respectées, il ne modifie rien.
Donc le code que l'on a écrit ne sert à rien... Désolé.
Donc sans y mettre le moindre code, cela devrait marcher. Refais un essai, pour voir.
Je supprime ma méthode setPassword(), tu veux dire ?
Oui, celle que l'on vient de créer et de vérifier... :cry:
Pour utiliser celle de la v5 de sfGuard qui fait déjà ces vérification de base :cry::cry:
Idem.. Si j' essai de modifier le pass, celui ne semble pas être pris en compte car je ne peux plus me logguer ensuite.
Si je ne change pas le champs password, mais un autre champs, le formulaire est validé mais j' ai l impression qu' il passe une chaine vide avant de chiffrer le passe en base. En appararence le pass n' est pas modifié mais en fait si et ne peut donc se logguer.
Quid de la fonction getPassword() dans ce cas. A part mettre le champs mot de passe à zero. Il est inutile non ?
La fonction setPassord de sfGuard commence par
ce qui élimine d'office tous password vide ou null arrivant. Si quant tu sauvegardes ton formulaire, le password vide modifie le mot de passe du user, c'est qu'il n'est pas vide... Il faudrait vérifier ce qui est envoyé du form a modèle.Code:
2
3
4
5if (!$password && 0 == strlen($password)) { return; }
Tu peux facilement savoir si le passe est changé, regarde le contenu de la base avant.
Tu peux modifier le comportement de sfGuard et notamment le moteur de hach. Je pense (a vérifier dans leur doc) qu'il doit être possible de ne pas chiffrer. Ce qui permettrait de suivre le comportement de l'objet.
La méthode getPassword qui met le champ à zéro ???
Ceci n'est pas possible. Un get ne peux pas modifier une valeur, cela serait contraire aux normes de développement. Et il m'étonnerait beaucoup qu'il y ait une telle erreur dans le code de sfGuard. D'autant qu'il n'y a pas de méthode getPassword définie dans leur code. Donc, en l'état, le getPassword va retourner la valeur du mot de passe haché. Pas très parlant. On utilisera généralement la méthode checkPassoword() qui permet de vérifier la concordance entre un mot de passe saisi et celui haché.
Oui la méthode getpassword() que tu m' avais conseillé dans mes modèles hérités de sfguard (voir quelques postes plus haut).
Si j' enlève cette méthode, le mot de passe hashé est affiché dans le champs mot de passe lorsqu' on édite un consultant par exemple.
le hic est que même si on ne modifie pas le pass, la chaine hashée devient la "chaine à hasher". Comme si on avait délibérément saisie cette chaine en clair dans le formulaire. Du coup le mot de passe change a chaque édition.
Est ce que tu me suis?
Oui, logique.
Le problème est que checkPasswordByGuard() qui est utilisé par défaut par sfGuard pour vérifier le mot de passe récupère celui-ci dans l'objet par un getPassword(). Donc si on le fait afficher à blanc...
Je manque de temps pour tester mais je pense avoir une solution.
Il faudrait modifier (encore !) le form. Modifier le widget password, en changer le nom. Par exemple passwordModify.
Ensuite créer deux méthodes sur le modèle. Une getPasswordModify() qui retourne une chaine nul. Et une setPassordModify() qui renvoie sur setPassord().
Je pense qu'ainsi on devrait biaiser notre amis sfGuard et garder la possibilité de changer la valeur du mot de passe.
Seul impossibilité, celle de supprimer le password d'un user.
Et tu mets quoi dans ces fonctions ?Citation:
Envoyé par Michel Rotta
Si tu crées un champ PasswordModify dans le form, il fera appel à ces getter et setter et cela devrait, enfin, marcher.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Merci.
Mais comment ajouter ce champs dans mon form qui est autogénéré ?
Je peux juste activer/désactiver modifier le label via le generator.yml mais pas ajouter un champs qui n' existe pas dans mon modèle ?
Tu as deux endroit où tu peux jouer sur les champs, et deux manières de faire.
Si tu veux rester full générateur, tu peux ajouter des champs en passant par des partiels. Par contre, je ne sais plus comment est transformé le nom pour le récupérer au retour.
L'autre solution est de modifier le form sur lequel s'appuie ton générateur. Tu dérive le form général ou le form de base, en fonction de ton application. Dans ce nouveau form, enfant du form d'origine, tu rajoutes (setWidget()) le champs (et éventuellement tu vires ceux qui ne t'intéressent pas) globalement, tu peux y faire tout une partie de la configuration présente dans le generator.yml et plus souple. Dans le générator, tu vas lui spécifier que tu travail avec cette form pour les édition et/ou création. Et le tour est joué. C'est cette méthode que j'utilise.
En fait en testant j' ai toujours un problème sur l' edition de l enregistrement.
La valeur de mon mon champs password n' étant plus visible dans le formulaire d' edition, je suis obligé de le resaisir à la validation du formulaire pour pouvoir faire l' update.
Embettant car je ne suis pas censé le connaitre par coeur.
Je veux bien que tu me montre un exemple que tu utilises pour gérer ce cas.
Merci encore de ton aide.
L'exemple est déjà donné plus haut.
Si la saisie est vide, alors pas de saisie.
C'est le comportement de base des objets sfGuard.
Le fait de laisser le passe à blanc signifie qu'il ne doit pas être modifié (et non pas qu'il doit être supprimé).