|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Futur Membre du Club
![]() Mickael Étudiant Inscription : novembre 2008 Messages : 66 ![]() |
Bonjour a vous,
Encore une fois je rencontre un problème que je n'arrive pas a résoudre seul, il s'agit en faite d'une page contenant deux formulaires, le premier permet de créer un utilisateur, a partir du formulaire sfGuardRegisterForm (un peu surcharger en faite), le suivant est un formulaire permettant de se connecter directement si on possède déjà un compte utilisateur et là j'utilise encore une fois un formulaire existant dans sfGuardDoctrine : BasesfGuardFormSignin. Le premier formulaire est traité dans l'action appelante, le deuxième est traité par l'action dédié de sfGuardDoctrine prévue à cette effet. Le premier formulaire fonctionne correctement, le soucis provient du deuxième qui me génére un CSRF attack detected, or en utilisant le formulaire l'action de connection de base du plugin et en y insérant les mêmes informations cela fonctionne. Merci d'avance. Cordialement, Mickael |
|
00
|
|
|
#2 |
![]() ![]() Michel RottaResponsable d'exploitation informatique Inscription : septembre 2005 Messages : 4 913 ![]() |
Fonctionnement de la protection CSRF.
Lors de l'initialisation du formulaire, form génère un tokenCSRF qui est envoyé avec le formulaire dans un champ caché. Au retour du formulaire, form (validation) vérifie que le tokenCSRF est présent et identique à celui de l'allé. Ceci permet de s'assurer que la réponse provient bien d'une personnes (d'un ordi) qui a reçu le formulaire d'origine (ou est arrivé à l'intercepter). Ton problème vient du fait que lors de la validation ton form n'a pas le bon token à valider et donc considère qu'il y a attaque. A mon avis ton ou tes templates doivent ce mélanger les pinceaux et tu dois avoir deux balises form incluent l'une dans l'autre au lieu de les avoir l'une après l'autre. Vérifies, corriges et tu seras bon.
__________________
Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).
|
|
00
|
|
|
#3 |
|
Futur Membre du Club
![]() Mickael Étudiant Inscription : novembre 2008 Messages : 66 ![]() |
Bonsoir,
Je te remercie, je connaissais déjà le fonctionnement du token c'est pourquoi cette erreur ma surprise, d'autant plus que mon fichier était bien constitué (structure HTML j'entends). J'ai trouvé la solution par hasard en faite, mon formulaire était une instance de BasesfGuardFormSignin, il a juste fallu que je le change en une instance de sfGuardFormSignin pour que cela fonctionne, du coup je ne comprend pas très bien car en visualisant le formulaire résultant de la classe BasesfGuardFormSignin il y avait bien le champs caché _csrf_token ce qui est normal car ce dernier est plus en amont dans l'arbre d'héritage. Peu-être pourras tu m'éclairer une fois de plus |
|
00
|
|
|
#4 |
![]() ![]() Michel RottaResponsable d'exploitation informatique Inscription : septembre 2005 Messages : 4 913 ![]() |
Je ne vois pas très bien non.
La solution me semble un peu trop miraculeuse pour être honnête. En effet, sauf erreur sfGuardFormSignin est juste un enfant sans modification de BaseGuardFormSignin. Instancier l'un où l'autre ne devrait rien changer. Et je ne vois pas comment ceci pourrait générer ton message d'erreur. Avantage de la pratique (ça marche mais on ne sait pas pourquoi) sur la théorie (ça ne marche pas mais on sait pourquoi).
__________________
Si tu donnes un poisson à un homme, il mangera un jour. Si tu lui apprends à pêcher, il mangera toujours (Lao Tseu).
|
|
00
|
|
|
#5 |
|
Futur Membre du Club
![]() Mickael Étudiant Inscription : novembre 2008 Messages : 66 ![]() |
Citation de Albert Einstein
Au moins mon problème est résolu. merci a toi |
|
00
|
Copyright © 2000-2012 - www.developpez.com