[réglé]Le multiclic

[NicoMSEvent]

J'ai tout capté du premier coup. C'est bougrment intelligent tout ça, je pense que je vais m'en inspirer
Je penses que tu pourrais utiliser les cookies putot que le post ou le get, ça serait plus propre...

[Sephi-Chan]

Oui mais les gens qui les refusent risquent d'outrepasser la protection.

[Plume]

Bonjour ^^

Didju ! Une règle d'or est pourtant de ne jamais se fier à l'utilisateur ! Donc tout ce qui se rapporte au client, t'oublies ! Grrr !!

@ tchaOo°

[NicoMSEvent]

donc les valeurs passée en GET ou en POST (qui viennent du client), on ne doit pas s'y fier non plus... de même que le REFERER. Donc, a un moment ou un autre, il faut faire quelques concessions.

Edit : bravo pour ton 1.500 eme post damën!!!

[Mysterarts]

+1 pour NicoMSEvent, on a pas trop le choix, je trouve...

Quand je pense qu'on fêtais le 1000em message de DämEn il n'a pas longtemps ^^

Mysterarts, t'organise quelque chose ?

[Sephi-Chan]

Dans un sens, c'est vrai que le cookie convient. On considère alors l'absence de données comme une multi-clic.

[Plume]

Bonjour ^^

Merci messieurs !
J'espère bientôt atteindre les 2.000. J'avais dit que c'était ma prochaine étape J'vous invite tous chez moi quand même

Revenons aux choses sérieuses.

de même que le REFERER

Si y a bien un truc dont je me méfie, c'est bien le REFERER, tu sais pas d'où le client peut arriver ..

donc les valeurs passée en GET ou en POST (qui viennent du client), on ne doit pas s'y fier non plus...

Evidemment, y a une limite. Je préfère travailler au plus avec POST, rares sont mes pratiques avec GET. Déjà, l'utilisateur ne peut pas les désactiver. Et avec POST, il n'est pas aussi simple de manipuler le traitement. Après, c'est à toi de t'assurer d'un bon traitement. Evidemment, il n'y a pas de solutions miracles toutes faites. A toi de retrousser tes manches, mais y a des choses que je pense qu'il faut préférer éviter.

Dans un sens, c'est vrai que le cookie convient. On considère alors l'absence de données comme une multi-clic.

Là encore, je pense qu'il s'agit d'un mauvais raisonnement. Tu n'as pas à contraindre l'utilisateur. C'est mal vu, et puis d'un côté éthique de développeur, le principe c'est d'adapter la machine à l'homme, et pas à l'homme de s'adapter à la machine. Donc tu dois faire en sorte que l'utilisateur ait le moins de contraintes à assumer.

@ tchaOo°

[Sephi-Chan]

Oui, c'était en partie pourquoi je ne voulais pas du cookie.

La meilleure méthode est de passer par un POST, car c'est plus compliqué à détourner.

J'en profite pour citer l'extension Web developer de Firefox, qui permet de modifier les formulaires :


Cela offre quelques moyens pour éprouver un formulaire.

Dans le cas de l'absence d'une variable transmise par POST, c'est forcément qu'elle a été détournée.


Sephi-Chan

[Plume]

Bonjour ^^

La meilleure méthode est de passer par un POST, car c'est plus compliqué à détourner.

C'est bien ce que je pense/dis

Par contre, je ne comprend pas bien ce que ça change dans la mise en application d'avoir transformé la méthode du formulaire ..

@ tchaOo°

[Mysterarts]

ET bien tous simplement, une fois la variable passé en GET, on peut voir et le nom des variables qui transitent ainsi que sa valeur, et comme c'est du GET, on peut la modifier ! Bien sur on peut très bien protéger ça mieux, mais quand même c'est la preuve de la facilité de piratage des formulaires de base...