je cherche une méthode permettant de désactiver les boutons "précédent" et "suivant" du navigateur.
Et le site de Coca-Cola cherche une méthode pour empêcher le navigateur d'aller ensuite sur le site de Pepsi-Cola. Bien évidemment, ce n'est pas possible : l'utilisateur peut toujours naviguer où il veut et comme il veut.
Avec les boutons « précédent » et « suivant » c'est pareil.
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt pourquoi tu voudrais faire ça. Si c'est parce que la page précédente fait une création d'article en base de données et que tu n'as pas prévu le cas où l'utilisateur demanderait deux fois la création du même article, ce qui est le cas classique, cherche plutôt comment détecter les doublons.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
je cherche une méthode permettant de désactiver les boutons
"précédent" et "suivant" du navigateur.
Et le site de Coca-Cola cherche une méthode pour empêcher le navigateur
d'aller ensuite sur le site de Pepsi-Cola. Bien évidemment, ce n'est pas
possible : l'utilisateur peut toujours naviguer où il veut et comme il veut.
Avec les boutons « précédent » et « suivant » c'est pareil.
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt
pourquoi tu voudrais faire ça. Si c'est parce que la page précédente
fait une création d'article en base de données et que tu n'as pas
prévu le cas où l'utilisateur demanderait deux fois la création du
même article, ce qui est le cas classique, cherche plutôt comment
détecter les doublons.
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
je cherche une méthode permettant de désactiver les boutons "précédent" et "suivant" du navigateur.
Et le site de Coca-Cola cherche une méthode pour empêcher le navigateur d'aller ensuite sur le site de Pepsi-Cola. Bien évidemment, ce n'est pas possible : l'utilisateur peut toujours naviguer où il veut et comme il veut.
Avec les boutons « précédent » et « suivant » c'est pareil.
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt pourquoi tu voudrais faire ça. Si c'est parce que la page précédente fait une création d'article en base de données et que tu n'as pas prévu le cas où l'utilisateur demanderait deux fois la création du même article, ce qui est le cas classique, cherche plutôt comment détecter les doublons.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Eric
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt pourquoi tu voudrais faire ça. Si c'est parce que la page précédente fait une création d'article en base de données et que tu n'as pas prévu le cas où l'utilisateur demanderait deux fois la création du même article, ce qui est le cas classique, cherche plutôt comment détecter les doublons.
Plus simple, faire un header('location:ok.html'); en php : la page d'ajout dans la bdd n'apparait ni dans l'historique, ni dans les boutons précédent, suivant, seulement y apparaissent le formulaire, et la page de confirmation.
Le procédé peut sembler lourd (il faut prévoir 3 pages), mais imparrable.
Eric
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt
pourquoi tu voudrais faire ça. Si c'est parce que la page précédente
fait une création d'article en base de données et que tu n'as pas
prévu le cas où l'utilisateur demanderait deux fois la création du
même article, ce qui est le cas classique, cherche plutôt comment
détecter les doublons.
Plus simple, faire un header('location:ok.html'); en php : la page
d'ajout dans la bdd n'apparait ni dans l'historique, ni dans les
boutons précédent, suivant, seulement y apparaissent le formulaire,
et la page de confirmation.
Le procédé peut sembler lourd (il faut prévoir 3 pages), mais
imparrable.
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt pourquoi tu voudrais faire ça. Si c'est parce que la page précédente fait une création d'article en base de données et que tu n'as pas prévu le cas où l'utilisateur demanderait deux fois la création du même article, ce qui est le cas classique, cherche plutôt comment détecter les doublons.
Plus simple, faire un header('location:ok.html'); en php : la page d'ajout dans la bdd n'apparait ni dans l'historique, ni dans les boutons précédent, suivant, seulement y apparaissent le formulaire, et la page de confirmation.
Le procédé peut sembler lourd (il faut prévoir 3 pages), mais imparrable.
Eric
david
salut,
en fait, cela provoque une perturbation avec les différents cache (local au client, sur le serveur).
Je ne sais pas grand chose sur ce problème (car je n'ai pas développé les pages). je pense qu'elles sont en asp. J'ai donc proposé (car je soupsonnais que vider l'historique ou masquer ces boutons n''était pas possible) de : - ajouter (si les pages sont en ASP), un response.expires = -10000 (expire tout de suite) dans les en-têtes de chaque page serveur. - ajouter un window.open('..', '_blank', 'toolbar:no;menubar:no') juste après l'identification - ajouter sur chaque page 2 scripts (chargement/déchargement) de respectivement test d'existance de cookies et création de cookies.
Je pense que cela devrait suffire à éviter les perturbation d'affichage en cas d'utilisation du cache (en admétant que leur pages serveur soient bien développées comme tu l'as dit).
Merci pour ton aide, à la prochaine... David
salut,
en fait, cela provoque une perturbation avec les différents cache
(local au client, sur le serveur).
Je ne sais pas grand chose sur ce problème (car je n'ai pas
développé les pages). je pense qu'elles sont en asp.
J'ai donc proposé (car je soupsonnais que vider l'historique ou
masquer ces boutons n''était pas possible) de :
- ajouter (si les pages sont en ASP), un response.expires = -10000
(expire tout de suite) dans les en-têtes de chaque page serveur.
- ajouter un window.open('..', '_blank', 'toolbar:no;menubar:no')
juste après l'identification
- ajouter sur chaque page 2 scripts (chargement/déchargement) de
respectivement test d'existance de cookies et création de cookies.
Je pense que cela devrait suffire à éviter les perturbation
d'affichage en cas d'utilisation du cache (en admétant que leur pages
serveur soient bien développées comme tu l'as dit).
en fait, cela provoque une perturbation avec les différents cache (local au client, sur le serveur).
Je ne sais pas grand chose sur ce problème (car je n'ai pas développé les pages). je pense qu'elles sont en asp. J'ai donc proposé (car je soupsonnais que vider l'historique ou masquer ces boutons n''était pas possible) de : - ajouter (si les pages sont en ASP), un response.expires = -10000 (expire tout de suite) dans les en-têtes de chaque page serveur. - ajouter un window.open('..', '_blank', 'toolbar:no;menubar:no') juste après l'identification - ajouter sur chaque page 2 scripts (chargement/déchargement) de respectivement test d'existance de cookies et création de cookies.
Je pense que cela devrait suffire à éviter les perturbation d'affichage en cas d'utilisation du cache (en admétant que leur pages serveur soient bien développées comme tu l'as dit).
Merci pour ton aide, à la prochaine... David
Olivier Miakinen
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt pourquoi tu voudrais faire ça. Si c'est parce que la page précédente fait une création d'article en base de données et que tu n'as pas prévu le cas où l'utilisateur demanderait deux fois la création du même article, ce qui est le cas classique, cherche plutôt comment détecter les doublons.
Plus simple, faire un header('location:ok.html'); en php : la page d'ajout dans la bdd n'apparait ni dans l'historique, ni dans les boutons précédent, suivant, seulement y apparaissent le formulaire, et la page de confirmation.
Attention quand même :
D'une part il ne faut pas mettre un lien relatif dans l'entête location (même si la plupart des navigateurs ont l'air de savoir s'en débrouiller, c'est explicitement interdit par la norme HTTP), le code sera donc différent selon que l'on est en HTTP ou en HTTPS. Avec l'espace requise, cela donne : header('Location: http://site/chemin/chemin/ok.html'); ou : header('Location: https://site/chemin/chemin/ok.html');
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur la page du formulaire et de cliquer une seconde fois sur OK.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt
pourquoi tu voudrais faire ça. Si c'est parce que la page précédente
fait une création d'article en base de données et que tu n'as pas
prévu le cas où l'utilisateur demanderait deux fois la création du
même article, ce qui est le cas classique, cherche plutôt comment
détecter les doublons.
Plus simple, faire un header('location:ok.html'); en php : la page
d'ajout dans la bdd n'apparait ni dans l'historique, ni dans les
boutons précédent, suivant, seulement y apparaissent le formulaire,
et la page de confirmation.
Attention quand même :
D'une part il ne faut pas mettre un lien relatif dans l'entête
location (même si la plupart des navigateurs ont l'air de savoir
s'en débrouiller, c'est explicitement interdit par la norme HTTP),
le code sera donc différent selon que l'on est en HTTP ou en HTTPS.
Avec l'espace requise, cela donne :
header('Location: http://site/chemin/chemin/ok.html');
ou :
header('Location: https://site/chemin/chemin/ok.html');
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur
la page du formulaire et de cliquer une seconde fois sur OK.
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Maintenant que tu sais que ce n'est pas possible, dis-nous plutôt pourquoi tu voudrais faire ça. Si c'est parce que la page précédente fait une création d'article en base de données et que tu n'as pas prévu le cas où l'utilisateur demanderait deux fois la création du même article, ce qui est le cas classique, cherche plutôt comment détecter les doublons.
Plus simple, faire un header('location:ok.html'); en php : la page d'ajout dans la bdd n'apparait ni dans l'historique, ni dans les boutons précédent, suivant, seulement y apparaissent le formulaire, et la page de confirmation.
Attention quand même :
D'une part il ne faut pas mettre un lien relatif dans l'entête location (même si la plupart des navigateurs ont l'air de savoir s'en débrouiller, c'est explicitement interdit par la norme HTTP), le code sera donc différent selon que l'on est en HTTP ou en HTTPS. Avec l'espace requise, cela donne : header('Location: http://site/chemin/chemin/ok.html'); ou : header('Location: https://site/chemin/chemin/ok.html');
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur la page du formulaire et de cliquer une seconde fois sur OK.
-- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
Eric
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur la page du formulaire et de cliquer une seconde fois sur OK.
Bien sur, comme toute solution, il y a des limites, mais vous met au défi de trouver une solution qui empêche l'utilisateur de cliquer deux fois sur OK ! Il n'a que recliquer sur le lien qui l'a amené à la page précédente :-)
Contrairement à un envoi "direct", où l'utilisateur peut réenvoyer INVOLONTAIREMENT la requête en actualisant la page, dans ce cas de la redirection, le réenvoi de données est VOLONTAIRE.
Les solutions proposées relèvent de la bidouille : attendre 15 secondes entre chaque envoi dans un forum, un numéro unique d'envoi pour détecter les double clics, mais il y demeure des limites !
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur
la page du formulaire et de cliquer une seconde fois sur OK.
Bien sur, comme toute solution, il y a des limites, mais vous met au
défi de trouver une solution qui empêche l'utilisateur de cliquer
deux fois sur OK !
Il n'a que recliquer sur le lien qui l'a amené à la page précédente
:-)
Contrairement à un envoi "direct", où l'utilisateur peut réenvoyer
INVOLONTAIREMENT la requête en actualisant la page, dans ce cas de la
redirection, le réenvoi de données est VOLONTAIRE.
Les solutions proposées relèvent de la bidouille : attendre 15
secondes entre chaque envoi dans un forum, un numéro unique d'envoi
pour détecter les double clics, mais il y demeure des limites !
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur la page du formulaire et de cliquer une seconde fois sur OK.
Bien sur, comme toute solution, il y a des limites, mais vous met au défi de trouver une solution qui empêche l'utilisateur de cliquer deux fois sur OK ! Il n'a que recliquer sur le lien qui l'a amené à la page précédente :-)
Contrairement à un envoi "direct", où l'utilisateur peut réenvoyer INVOLONTAIREMENT la requête en actualisant la page, dans ce cas de la redirection, le réenvoi de données est VOLONTAIRE.
Les solutions proposées relèvent de la bidouille : attendre 15 secondes entre chaque envoi dans un forum, un numéro unique d'envoi pour détecter les double clics, mais il y demeure des limites !
Olivier Miakinen
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur la page du formulaire et de cliquer une seconde fois sur OK.
Bien sur, comme toute solution, il y a des limites, mais vous met au défi de trouver une solution qui empêche l'utilisateur de cliquer deux fois sur OK !
Je ne relève pas le défi : comme je le disais dans mon premier article, on ne peut pas empêcher l'utilisateur de faire cela. C'est bien pour ça qu'il est stupide d'essayer, alors qu'il vaut mieux protéger l'appli pour qu'elle se comporte comme il faut *même si* l'utilisateur clique 1 000 fois sur OK.
Il n'a que recliquer sur le lien qui l'a amené à la page précédente :-)
Oui. Mais avec certains navigateurs (peut-être tous), il peut suffire d'une souris avec rebond (deux clics envoyés quand on n'en veut qu'un), ou bien d'une liaison internet lente.
Contrairement à un envoi "direct", où l'utilisateur peut réenvoyer INVOLONTAIREMENT la requête en actualisant la page, dans ce cas de la redirection, le réenvoi de données est VOLONTAIRE.
Pas forcément. Et même si c'était le cas, le concepteur d'un site web doit se protéger d'un éventuel envoi de données volontaire (et même malveillant) avec quelqu'un qui enverrait 1 000 requêtes POST à la minute (script shell + curl par exemple).
Les solutions proposées relèvent de la bidouille : attendre 15 secondes entre chaque envoi dans un forum, un numéro unique d'envoi pour détecter les double clics, mais il y demeure des limites !
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des bidouilles. La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément). Avec cette solution, on n'a pas à se soucier d'un utilisateur revenant N fois sur la même page et cliquant N fois sur OK, ni d'un malveillant envoyant 1 000 fois la même requête.
Cordialement, -- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur
la page du formulaire et de cliquer une seconde fois sur OK.
Bien sur, comme toute solution, il y a des limites, mais vous met au
défi de trouver une solution qui empêche l'utilisateur de cliquer
deux fois sur OK !
Je ne relève pas le défi : comme je le disais dans mon premier article,
on ne peut pas empêcher l'utilisateur de faire cela. C'est bien pour ça
qu'il est stupide d'essayer, alors qu'il vaut mieux protéger l'appli
pour qu'elle se comporte comme il faut *même si* l'utilisateur clique
1 000 fois sur OK.
Il n'a que recliquer sur le lien qui l'a amené à la page précédente
:-)
Oui. Mais avec certains navigateurs (peut-être tous), il peut suffire
d'une souris avec rebond (deux clics envoyés quand on n'en veut qu'un),
ou bien d'une liaison internet lente.
Contrairement à un envoi "direct", où l'utilisateur peut réenvoyer
INVOLONTAIREMENT la requête en actualisant la page, dans ce cas de la
redirection, le réenvoi de données est VOLONTAIRE.
Pas forcément. Et même si c'était le cas, le concepteur d'un site web
doit se protéger d'un éventuel envoi de données volontaire (et même
malveillant) avec quelqu'un qui enverrait 1 000 requêtes POST à la
minute (script shell + curl par exemple).
Les solutions proposées relèvent de la bidouille : attendre 15
secondes entre chaque envoi dans un forum, un numéro unique d'envoi
pour détecter les double clics, mais il y demeure des limites !
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des
bidouilles. La seule solution propre passe par une base de données
avec clé unique, calculée sur les données entrées par l'utilisateur
(et non pas en auto-incrément). Avec cette solution, on n'a pas à se
soucier d'un utilisateur revenant N fois sur la même page et cliquant
N fois sur OK, ni d'un malveillant envoyant 1 000 fois la même requête.
Cordialement,
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
D'autre part, je ne vois pas en quoi cela empêcherait de revenir sur la page du formulaire et de cliquer une seconde fois sur OK.
Bien sur, comme toute solution, il y a des limites, mais vous met au défi de trouver une solution qui empêche l'utilisateur de cliquer deux fois sur OK !
Je ne relève pas le défi : comme je le disais dans mon premier article, on ne peut pas empêcher l'utilisateur de faire cela. C'est bien pour ça qu'il est stupide d'essayer, alors qu'il vaut mieux protéger l'appli pour qu'elle se comporte comme il faut *même si* l'utilisateur clique 1 000 fois sur OK.
Il n'a que recliquer sur le lien qui l'a amené à la page précédente :-)
Oui. Mais avec certains navigateurs (peut-être tous), il peut suffire d'une souris avec rebond (deux clics envoyés quand on n'en veut qu'un), ou bien d'une liaison internet lente.
Contrairement à un envoi "direct", où l'utilisateur peut réenvoyer INVOLONTAIREMENT la requête en actualisant la page, dans ce cas de la redirection, le réenvoi de données est VOLONTAIRE.
Pas forcément. Et même si c'était le cas, le concepteur d'un site web doit se protéger d'un éventuel envoi de données volontaire (et même malveillant) avec quelqu'un qui enverrait 1 000 requêtes POST à la minute (script shell + curl par exemple).
Les solutions proposées relèvent de la bidouille : attendre 15 secondes entre chaque envoi dans un forum, un numéro unique d'envoi pour détecter les double clics, mais il y demeure des limites !
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des bidouilles. La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément). Avec cette solution, on n'a pas à se soucier d'un utilisateur revenant N fois sur la même page et cliquant N fois sur OK, ni d'un malveillant envoyant 1 000 fois la même requête.
Cordialement, -- Olivier Miakinen Troll du plus sage chez les conviviaux : le nouveau venu, avec son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
ASM
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des bidouilles. La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
-- Stephane Moriaux et son [moins] vieux Mac
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des
bidouilles. La seule solution propre passe par une base de données
avec clé unique, calculée sur les données entrées par l'utilisateur
(et non pas en auto-incrément).
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des bidouilles. La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
-- Stephane Moriaux et son [moins] vieux Mac
nico
ASM wrote:
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des bidouilles. La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
C'est effectivement une solution très interessante. Pour ASM : Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha. Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
++
ASM wrote:
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des
bidouilles. La seule solution propre passe par une base de données
avec clé unique, calculée sur les données entrées par l'utilisateur
(et non pas en auto-incrément).
Oui? tu peux expliquer ?
C'est effectivement une solution très interessante.
Pour ASM :
Lorsque tu reçois le message du client, tu en tire un identifiant
unique, comme par exemple un md5 ou sha.
Cet identifiant dépend du contenu du message ! Donc si un utilisateur
reposte le même message, celui-ci aura le même identifiant, et donc il
sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost
(volontaire ou pas, peu importe)
Beurk ! Comme tu le dis, ce ne sont pas des solutions mais des bidouilles. La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
C'est effectivement une solution très interessante. Pour ASM : Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha. Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
++
ASM
ASM wrote:
La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
Pour ASM :
Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha.
ha! ha! voilà qui est interressant ! et ne m'éclaire pas du tout ! (je suis une crasse en bdd et en bp d'autres choses) on va voir ce que nous en dit google.
Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
comment fait-il pour compléter, reprendre ?
doit-il attendre 1/4 d'heure ? ou simplement envoyer un nouveau post ?
sinon pour le fébrile du click souris et si le JS est activé le bouton submit peut passer en disabled au 1er click (ce qui ne résoud pas les forçages logiciels ou autres méchancetés)
-- Stephane Moriaux et son [moins] vieux Mac
ASM wrote:
La seule solution propre passe par une base de données
avec clé unique, calculée sur les données entrées par l'utilisateur
(et non pas en auto-incrément).
Oui? tu peux expliquer ?
Pour ASM :
Lorsque tu reçois le message du client, tu en tire un identifiant
unique, comme par exemple un md5 ou sha.
ha! ha! voilà qui est interressant !
et ne m'éclaire pas du tout !
(je suis une crasse en bdd et en bp d'autres choses)
on va voir ce que nous en dit google.
Cet identifiant dépend du contenu du message ! Donc si un utilisateur
reposte le même message, celui-ci aura le même identifiant, et donc il
sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost
(volontaire ou pas, peu importe)
comment fait-il pour compléter, reprendre ?
doit-il attendre 1/4 d'heure ?
ou simplement envoyer un nouveau post ?
sinon pour le fébrile du click souris et si le JS est activé
le bouton submit peut passer en disabled au 1er click
(ce qui ne résoud pas les forçages logiciels ou autres méchancetés)
La seule solution propre passe par une base de données avec clé unique, calculée sur les données entrées par l'utilisateur (et non pas en auto-incrément).
Oui? tu peux expliquer ?
Pour ASM :
Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha.
ha! ha! voilà qui est interressant ! et ne m'éclaire pas du tout ! (je suis une crasse en bdd et en bp d'autres choses) on va voir ce que nous en dit google.
Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
comment fait-il pour compléter, reprendre ?
doit-il attendre 1/4 d'heure ? ou simplement envoyer un nouveau post ?
sinon pour le fébrile du click souris et si le JS est activé le bouton submit peut passer en disabled au 1er click (ce qui ne résoud pas les forçages logiciels ou autres méchancetés)
-- Stephane Moriaux et son [moins] vieux Mac
CrazyCat
nico wrote:
C'est effectivement une solution très interessante. Pour ASM : Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha. Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
Et simplement utiliser l'attribut "unique" du champ, c'est pas plus simple?
-- Aide informatique: http://help-info.forumactif.com Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
nico wrote:
C'est effectivement une solution très interessante.
Pour ASM :
Lorsque tu reçois le message du client, tu en tire un identifiant
unique, comme par exemple un md5 ou sha.
Cet identifiant dépend du contenu du message ! Donc si un utilisateur
reposte le même message, celui-ci aura le même identifiant, et donc il
sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost
(volontaire ou pas, peu importe)
Et simplement utiliser l'attribut "unique" du champ, c'est pas plus simple?
--
Aide informatique: http://help-info.forumactif.com
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
C'est effectivement une solution très interessante. Pour ASM : Lorsque tu reçois le message du client, tu en tire un identifiant unique, comme par exemple un md5 ou sha. Cet identifiant dépend du contenu du message ! Donc si un utilisateur reposte le même message, celui-ci aura le même identifiant, et donc il sera impossible de l'enregistrer en bdd.
Donc cette solution est très interessante pour éviter le multipost (volontaire ou pas, peu importe)
Et simplement utiliser l'attribut "unique" du champ, c'est pas plus simple?
-- Aide informatique: http://help-info.forumactif.com Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
