Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
il suffit de tester le resultat du formulaire et si la reponse est positive, faire une redirection : header('Location ...');
Olivier Miakinen
Lorsque je valide un formulaire, j'insere un element dans un base de données et j'affiche une page.
Ok.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Normal.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
La discussion revient assez régulièrement sur le sujet. Comme tu ne peux pas empêcher un utilisateur (malicieux ou non) de t'envoyer 15 fois la même requête (resp. 1 000 fois pour l'utilisateur malicieux), le seul moyen de t'en protéger consiste à bien choisir la clé unique dans ta base de données, clé unique qui fera que les 999 nouvelles requêtes ne modifieront pas ta base de données.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Lorsque je valide un formulaire, j'insere un element dans un base de données
et j'affiche une page.
Ok.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la
requete est à nouveau envoyé.
Normal.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se
prémunir de cela et par quelle technique.
La discussion revient assez régulièrement sur le sujet. Comme tu ne peux
pas empêcher un utilisateur (malicieux ou non) de t'envoyer 15 fois la
même requête (resp. 1 000 fois pour l'utilisateur malicieux), le seul
moyen de t'en protéger consiste à bien choisir la clé unique dans ta
base de données, clé unique qui fera que les 999 nouvelles requêtes ne
modifieront pas ta base de données.
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Lorsque je valide un formulaire, j'insere un element dans un base de données et j'affiche une page.
Ok.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Normal.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
La discussion revient assez régulièrement sur le sujet. Comme tu ne peux pas empêcher un utilisateur (malicieux ou non) de t'envoyer 15 fois la même requête (resp. 1 000 fois pour l'utilisateur malicieux), le seul moyen de t'en protéger consiste à bien choisir la clé unique dans ta base de données, clé unique qui fera que les 999 nouvelles requêtes ne modifieront pas ta base de données.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
bruno at modulix
J-F Portala wrote: (snip)
Lorsque je valide un formulaire, j'insere un element dans un base de données et j'affiche une page.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Normal.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
N'en déplaise à John, ma solution (enfin, celle que j'utilise, ce n'est pas moi qui l'ait inventée !-)) est d'utiliser un redirect si le traitement du POST est ok. C'est probablement la solution la plus simple à mettre en oeuvre, et celle qui respecte le plus le protocole HTTP (cf http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
J-F Portala wrote:
(snip)
Lorsque je valide un formulaire, j'insere un element dans un base de données
et j'affiche une page.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la
requete est à nouveau envoyé.
Normal.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se
prémunir de cela et par quelle technique.
N'en déplaise à John, ma solution (enfin, celle que j'utilise, ce n'est
pas moi qui l'ait inventée !-)) est d'utiliser un redirect si le
traitement du POST est ok. C'est probablement la solution la plus simple
à mettre en oeuvre, et celle qui respecte le plus le protocole HTTP (cf
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Lorsque je valide un formulaire, j'insere un element dans un base de données et j'affiche une page.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Normal.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
N'en déplaise à John, ma solution (enfin, celle que j'utilise, ce n'est pas moi qui l'ait inventée !-)) est d'utiliser un redirect si le traitement du POST est ok. C'est probablement la solution la plus simple à mettre en oeuvre, et celle qui respecte le plus le protocole HTTP (cf http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
ftc
Bonjour, je suis confronte au probleme suivant.
Lorsque je valide un formulaire, j'insere un element dans un base de données et j'affiche une page.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
C'est un problème auquel tout dev PHP se trouve confronté à un moment ou un autre.
Une solution possible est de généré un token ( identifiant unique ) dans la page appelante et tu stocke ce token en session et tu le met dans le formulaire de la page appelante.
Sur la page de traitement, tu vérifies que le token est présent dans les champs fournis,si oui tu fais tes traitement et tu supprime le token de la session. Si l'utilisateur rafraîchit a page, le token ne sera plus en session, tu n'effectues pas les traitements.
Bonjour,
je suis confronte au probleme suivant.
Lorsque je valide un formulaire, j'insere un element dans un base de données
et j'affiche une page.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la
requete est à nouveau envoyé.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se
prémunir de cela et par quelle technique.
C'est un problème auquel tout dev PHP se trouve confronté à un moment ou
un autre.
Une solution possible est de généré un token ( identifiant unique ) dans
la page appelante et tu stocke ce token en session et tu le met dans
le formulaire de la page appelante.
Sur la page de traitement, tu vérifies que le token est présent dans les
champs fournis,si oui tu fais tes traitement et tu supprime le token de
la session. Si l'utilisateur rafraîchit a page, le token ne sera plus en
session, tu n'effectues pas les traitements.
Lorsque je valide un formulaire, j'insere un element dans un base de données et j'affiche une page.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
C'est un problème auquel tout dev PHP se trouve confronté à un moment ou un autre.
Une solution possible est de généré un token ( identifiant unique ) dans la page appelante et tu stocke ce token en session et tu le met dans le formulaire de la page appelante.
Sur la page de traitement, tu vérifies que le token est présent dans les champs fournis,si oui tu fais tes traitement et tu supprime le token de la session. Si l'utilisateur rafraîchit a page, le token ne sera plus en session, tu n'effectues pas les traitements.
clifden
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
Pour ma part, j'utilise une technique un peu lourde, mais qui est sure de marcher à tout les coup (au contraire de l'utilisation de HTTP_REFERER)
J'ai conçu la classe suivante: http://www.phpclasses.org/browse/package/2928.html
Son principe: cree un hash aleatoire, avec un critère adossé: * nombre d'utilisation max * moment limite de validité
Ensuite, la fonction de verif, ou brule une utilisation ou verifie que le moment n'est pas dépassé.
Elle utilise une table mysql
Dans ton cas, tu créé un hash avec un nombre d'utilisation max=1, tu le met en champ hidden de ton formulaire. Quand tu reçoit les données, tu verifie le hash avec la methode, et celle ci te dira si c'est la première et unique fois que tu l'utilise, sinon, tu peut le savoir et gerer l'erreur. Un internaute qui post plusieurs fois sera averti et de ton coté tu ne fera pas plusieurs insert.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la
requete est à nouveau envoyé.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se
prémunir de cela et par quelle technique.
Pour ma part, j'utilise une technique un peu lourde, mais qui est sure
de marcher à tout les coup (au contraire de l'utilisation de HTTP_REFERER)
J'ai conçu la classe suivante:
http://www.phpclasses.org/browse/package/2928.html
Son principe: cree un hash aleatoire, avec un critère adossé:
* nombre d'utilisation max
* moment limite de validité
Ensuite, la fonction de verif, ou brule une utilisation ou verifie que
le moment n'est pas dépassé.
Elle utilise une table mysql
Dans ton cas, tu créé un hash avec un nombre d'utilisation max=1, tu le
met en champ hidden de ton formulaire.
Quand tu reçoit les données, tu verifie le hash avec la methode, et
celle ci te dira si c'est la première et unique fois que tu l'utilise,
sinon, tu peut le savoir et gerer l'erreur. Un internaute qui post
plusieurs fois sera averti et de ton coté tu ne fera pas plusieurs insert.
Si je reactualise la page avec les commandes du navigateur, l'ensemble de la requete est à nouveau envoyé.
Cela ne me parait pas illogique, mais je voulais savoir si on pouvait se prémunir de cela et par quelle technique.
Pour ma part, j'utilise une technique un peu lourde, mais qui est sure de marcher à tout les coup (au contraire de l'utilisation de HTTP_REFERER)
J'ai conçu la classe suivante: http://www.phpclasses.org/browse/package/2928.html
Son principe: cree un hash aleatoire, avec un critère adossé: * nombre d'utilisation max * moment limite de validité
Ensuite, la fonction de verif, ou brule une utilisation ou verifie que le moment n'est pas dépassé.
Elle utilise une table mysql
Dans ton cas, tu créé un hash avec un nombre d'utilisation max=1, tu le met en champ hidden de ton formulaire. Quand tu reçoit les données, tu verifie le hash avec la methode, et celle ci te dira si c'est la première et unique fois que tu l'utilise, sinon, tu peut le savoir et gerer l'erreur. Un internaute qui post plusieurs fois sera averti et de ton coté tu ne fera pas plusieurs insert.
Olivier Miakinen
[...] le seul moyen de t'en protéger consiste à bien choisir la clé unique [...]
La collision de deux idées que j'avais en répondant a résulté en une réponse fausse. Désolé.
En réalité, il fallait lire : 1) Le seul moyen de t'en protéger consiste à contrôler l'unicité sur le serveur (aucun moyen basé sur le comportement du client n'est efficace, en particulier pas le header('Location:...')). 2) Pour contrôler l'unicité, un moyen (parmi d'autres) est une clé unique dans la base de données.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
[...] le seul moyen de t'en protéger consiste à bien choisir la
clé unique [...]
La collision de deux idées que j'avais en répondant a résulté en une
réponse fausse. Désolé.
En réalité, il fallait lire :
1) Le seul moyen de t'en protéger consiste à contrôler l'unicité sur
le serveur (aucun moyen basé sur le comportement du client n'est
efficace, en particulier pas le header('Location:...')).
2) Pour contrôler l'unicité, un moyen (parmi d'autres) est une clé
unique dans la base de données.
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
[...] le seul moyen de t'en protéger consiste à bien choisir la clé unique [...]
La collision de deux idées que j'avais en répondant a résulté en une réponse fausse. Désolé.
En réalité, il fallait lire : 1) Le seul moyen de t'en protéger consiste à contrôler l'unicité sur le serveur (aucun moyen basé sur le comportement du client n'est efficace, en particulier pas le header('Location:...')). 2) Pour contrôler l'unicité, un moyen (parmi d'autres) est une clé unique dans la base de données.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Patrick Mevzek
N'en déplaise à John, ma solution (enfin, celle que j'utilise, ce n'est pas moi qui l'ait inventée !-)) est d'utiliser un redirect si le traitement du POST est ok. C'est probablement la solution la plus simple à mettre en oeuvre, et celle qui respecte le plus le protocole HTTP (cf http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
Ah ? Vous pouvez nous citer les «autres» qui respectent «moins» (selon vous) le protocole HTTP ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
N'en déplaise à John, ma solution (enfin, celle que j'utilise, ce n'est
pas moi qui l'ait inventée !-)) est d'utiliser un redirect si le
traitement du POST est ok. C'est probablement la solution la plus simple
à mettre en oeuvre, et celle qui respecte le plus le protocole HTTP (cf
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
Ah ? Vous pouvez nous citer les «autres» qui respectent «moins» (selon
vous) le protocole HTTP ?
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
N'en déplaise à John, ma solution (enfin, celle que j'utilise, ce n'est pas moi qui l'ait inventée !-)) est d'utiliser un redirect si le traitement du POST est ok. C'est probablement la solution la plus simple à mettre en oeuvre, et celle qui respecte le plus le protocole HTTP (cf http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html).
Ah ? Vous pouvez nous citer les «autres» qui respectent «moins» (selon vous) le protocole HTTP ?
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
