Oui, il s’agit d’un formulaire d’inscription avec des cases à cocher,
des champs pour les coordonnées et un captcha (simple_captcha) pour
valider le tout. Apparemment c’est la seule personne à qui le
problème est arrivé (3 fois de suite). Cette même personne à
ensuite réussi à envoyer des infos via le formulaire de contact (qui
fonctionne de la même manière, sans les cases à cocher) sans
problème.
Si le formulaire A ne marche pas et le formulaire B marche, il faut
examiner attentivement les codes des deux formulaires, simplifier
les formulaires en reproduisant le bug, repérer les différences.
Vérifier les paramètres (notamment l’authenticity_token) dans
les logs. Bref, débugger.
Si déjà tu n’arrives pas à reproduire son bug, t’es mal parti.
problème.
Si ca marche pour toi le problème n’est pas dans ton code de
formulaire.
Le protect_from_forgery est une technique pour éviter que des
formulaires soient posté à l’insu de l’utilisateur en exploitant une
failles xss et une session persistante chez l’utilisateur (Cross
Server Request Forgery).
Ca consiste en l’ajout d’un champ hidden au formulaire qui contient
une valeur déterministe (liée à la session jusqu’à maintenant mais
dans rails edge ce n’est plus le cas). Cette valeur est soumise avec
le formulaire et vérifié coté serveur, si la valeur diffère entre
celle soumise et celle attendue l’exception
ActionController::InvalidAuthenticityToken est levée.
Il faut donc dans le cas de ton utilisateur vérifié qu’est-ce qui est
envoyé comme paramètre (en particulier si il y a le token_id) est
passé.
Plusieurs raisons pour que ca foire:
une erreur dans le formulaire qui fait que le hidden field
n’apparait pas (ce qui ne doit pas être ton cas puisque ca marche avec
toi).
une page qu’on a oublié de rechargé depuis longtemps et qui le
session_id qui a changé depuis le temps parce que le user s’est logué
ou la session a
expirée - un mauvais support des cookies par le navigateur client
un problème de stabilité coté gestion des sessions qui change les
session_id, ou carrement une desactivation des sessions
si tu n’est pas en CookieStore un mauvais paramétrage de la
secret_key du protect_from_forgery qui est différente d’un controller
à l’autre et rails se mélange les pinceaux (ca a été assez longtemps
le cas mais plus depuis Rails2.2)
A priori je ne vois pas d’autres causes, la plus probable reste le
paramétrage de la secret key et un comportement deviant de ton client
(qui ne recharge pas ses pages et ouvrent plein d’onglet).
La solution finale étant la desactivation du protect_from_forgery, ca
n’est pas dramatique si tu es bien protégé contre le xss mais c’est
dommage.