Bonjour,

Je suis confronté à un problème avec le CSRF Token. J'utilise le Framework Symfony en version 4.3.

J'ai construit un formulaire de login sans utiliser l'outil qui en génère tout seul. Il se trouve qu'environ 20% du temps mon formulaire ne se valide pas et qu'on soit obligé de refaire la procédure de connexion. J'utilise la fonction suivante pour valider (fonction du FormBuilder) :

$form->isValid()

En debugant, j'obtiens que le CSRF Token n'est pas valide. D'un côté en session dans _sf2_attributes['_csrf/https-form'] j'obtiens une valeur et dans mon formulaire la valeur est différente, au deuxième essai les deux coïncident ... Impossible de comprendre d'où cela pourrait venir. D'après les premières infos que j'ai pu lire sur internet, cela viendrait de la session, mais celle-ci est bien déclarée.

À savoir que ma session peut être amenée à stocker un token, tout comme l'URL. Je ne sais pas si cela peut avoir une incidence, je préfère préciser.

Donc je fais appel à votre aide, pour m'aiguiller vers une solution. Si jamais une portion de code vous est nécessaire je vous fournirai ça !

Merci d'avance.

-
Edité par Logeur 7 octobre 2020 à 14:38:08

Salut

Est-ce que par hasard ton site n'est pas obligatoirement en HTTPS, sauf ta page de connexion qui elle serait obligatoirement/uniquement en HTTPS ?

Bonjour,

Merci pour ta réponse, alors tout le site est en HTTPS, tout comme ma page de connexion !

OK, c'est donc pas ce que je pensais. Il arrive que les cookies ne soient pas transmis lors du changement de protocole, et comme la session PHP utilise souvent le cookie pour faire le lien…

Tu n'ouvrirais pas deux onglets en parallèle, par hasard ?

Il se peut que deux onglets du même site soient ouverts en même temps, mais sur la page de login, si le token utilisateur est présent en session je redirige directement vers la page principale.

Est il possible que Symfony ne transmette pas correctement l'information dans la Session PHP ?

Et je me posais la question, si je pouvais outrepasser la fonction isValid de Symfony en gérant le CSRF Token moi même, mais j'ai peur de perdre des fonctionnalités importantes de cette fonction. Je n'ai pas réussi à trouver ce qu'elle vérifie à part le CSRF token. Est ce raisonnable ?

Attention : suivant comment est géré le token CSRF, si tu as deux onglets avec des formulaires d'ouvert et que tu soumets le premier chargé, il peut attendre le jeton CSRF du second parce qu'il y aura eu écrasement.

Les jetons CSRF sont "catégorisés"/créés pour "un type de formulaire", je ne me suis pas vraiment penché là-dessus. La seule fois où j'ai eu un souci avec, c'était sur une page qui listait des options suppressibles une à une avec un formulaire qui contenait deux champs cachés dont le token, et comme j'en générais un par ligne, si je ne supprimais pas le dernier de la liste, le jeton n'était pas valable. J'ai fini par rendre le formulaire manuellement et pour le token, j'ai appelé {{ csrf('form') }} où 'form' est cette "catégorie" de formulaire. Je ne sais plus trop comment j'ai trouvé cette valeur. Et du coup, plus de souci de validation du formulaire dans le contrôleur.

Ok c'est bon à savoir ! Mais du coup le seul formulaire que j'ai se trouve bien sur la page de Login ensuite plus aucun formulaire.

J'ai essayé de rendre le formulaire manuellement aussi, mais toujours le même problème ! Et voilà le résultat des jetons en session et dans le formulaire !

Et après la revalidation du formulaire, juste après avoir obtenu les 2 premiers screens.

Là cela sera peut être plus clair, mais ma session a comme "un tour d'avance", on retrouve exactement le même token que sur la première image, comme si le token du formulaire avait du retard ... Je ne sais pas à quoi cela est dû et que faire de cette information. J'ai l'impression de louper quelque chose ...

J'aimerai rajouter aussi une information, qui pourrait être importante.

Lorsque je me connecte avec le formulaire, quand il ne fonctionne pas, la console me renvoie ce warning : "Le cookie « PHPSESSID » a été rejeté car il a déjà expiré."