Salut,
si c'est anti-CSRF, le but est de rendre le formulaire imprévisible, donc impossible d'utiliser un seul token pour tout le site et tout le monde. A la rigueur, un seul token par joueur pour tout le site, c'est à voir... Mais niveau sécurité, mieux vaut lui attribuer une date d'expiration.
En tous cas, le token doit être différent d'un utilisateur à l'autre (sinon, le pirate s'inscrit, récupère le token, et l'intègre à ses requêtes CSRF ce qui ne sert donc à rien).
Consulte les bibliothèques anti-CSRF (Symphony doit en avoir une) pour les infos type durée d'expiration: tu les trouveras surement dans les paramètres de configuration de ces libs.
Il existe aussi un autre mécanisme anti-CSRF, basé sur des headers HTTP standards, mais je ne m'en rappelle plus de tête. Tu les trouveras sur En fait, il n'y est pas, mais je te conseille de faire le tour de la Cheat Sheet CSRF de l'OWASP.
[Edit] Autant mettre le lien...
A propos, j'aime bien le Double Submit Cookie, qui évite de stocker un token anti-CSRF coté serveur.
Sinon, il y a le Referer HTTP qui peut convenir, avec un fallback si besoin sur un formulaire à token (ainsi, on gère 80% des cas avec simplement le Referer, et on a un seul formulaire avec token, celui de fallback)
si c'est anti-CSRF, le but est de rendre le formulaire imprévisible, donc impossible d'utiliser un seul token pour tout le site et tout le monde. A la rigueur, un seul token par joueur pour tout le site, c'est à voir... Mais niveau sécurité, mieux vaut lui attribuer une date d'expiration.
En tous cas, le token doit être différent d'un utilisateur à l'autre (sinon, le pirate s'inscrit, récupère le token, et l'intègre à ses requêtes CSRF ce qui ne sert donc à rien).
Consulte les bibliothèques anti-CSRF (Symphony doit en avoir une) pour les infos type durée d'expiration: tu les trouveras surement dans les paramètres de configuration de ces libs.
Il existe aussi un autre mécanisme anti-CSRF, basé sur des headers HTTP standards, mais je ne m'en rappelle plus de tête. Tu les trouveras sur En fait, il n'y est pas, mais je te conseille de faire le tour de la Cheat Sheet CSRF de l'OWASP.
[Edit] Autant mettre le lien...
A propos, j'aime bien le Double Submit Cookie, qui évite de stocker un token anti-CSRF coté serveur.
Sinon, il y a le Referer HTTP qui peut convenir, avec un fallback si besoin sur un formulaire à token (ainsi, on gère 80% des cas avec simplement le Referer, et on a un seul formulaire avec token, celui de fallback)