Confirmation mot de passe

C'est vrai, et pour l'utilisation de header:location, j'en suis, et je vais faire en sorte de ne pas le rester.
Mais l'utilisation d'une vérification côté client offre un confort d'utilisation indéniable à l'utilisateur. Toutefois, en effet, il
vaut mieux privilégier les vérifications côté serveur, et seulement ensuite penser au client plutôt que l'inverse.
Juste une note : vérifier certaines données côté client n'est plus long à coder que du côté serveur. Simplement, cela oblige
à une double présence de scripts dont l'objectif est le même. Le mieux serait donc certainement une automatisation des
vérifications. Quant au problème des ressources, c'était une erreur de l'évoquer ici, puisqu'il ne constitue pas une priorité lors
de ce genre d'implémentation.

Enfin, ma réaction a été vive parce que la votre me semblait déplacée : votre première réponse indiquait (et en majuscules) des
notions justes mais, à mes yeux, hors sujet. Ceci bien-sûr, si, comme je l'avais compris, le premier interrogateur avait juste
besoin de vérifier que l'utilisateur ne se trompe pas de mot de passe lors d'une inscription. Et dans l'emportement, j'ai voulu vous
écraser. Merci de ne pas être un moustique.

J'espère qu'ainsi, nous nous serons mis d'accord, ou tout du moins, je me serais mis d'accord avec vous. Quand bien même nous ne
l'étions pas dès le départ.

Re,

C'est vrai, et pour l'utilisation de header:location, j'en suis, et je vais faire en sorte de ne pas le rester.

A ce sujet, et pour répondre publiquement (déjà fait en privé) à
Davel_x, un paragraphe a été ajouté à la FAQ de ce forum détaillant le
fonctionnement de header() : http://faqfclphp.free.fr/#ss2.11

Mais l'utilisation d'une vérification côté client offre un confort d'utilisation indéniable à l'utilisateur.

Ca reste à voir. Je veux dire par là qu'une IHM bien foutue ne nécessite
pas nécessairement de solutions clientes pour ... être bien foutue :-)
Du moment que l'internaute n'a pas besoin de remplir de nouveau tous les
champs qui étaient corrects après détection d'erreur/incohérence, en ce
qui me concerne, ça suffit. Et pas besoin de JS pour ça.

Toutefois, en effet, il
vaut mieux privilégier les vérifications côté serveur, et seulement ensuite
penser au client plutôt que l'inverse.

Nous sommes bien d'accord. Une fois que les vérifications d'intégrité
ont été faites côté serveur, si un confort peut être apporté à
l'internaute par des scripts clients, on peut les ajouter. A condition
qu'ils ne gênent pas ceux qui les désactivent.

Enfin, ma réaction a été vive parce que la votre me semblait déplacée :
votre première réponse indiquait (et en majuscules) des
notions justes mais, à mes yeux, hors sujet.

Je n'entend nullement faire fuire les contributeurs, tous bénévoles, de
ce forum, mais une fois de plus je tiens à le souligner : il faut
essayer d'élever le débat. Si l'auteur de la question se pose ce genre
de problématiques basiques, je préfère répondre à côté de sa petite
question bien précise pour être sûr qu'il n'a pas un gros trou de
sécurité/intégrité des données dans son application. Je préfère vérifier
qu'il fait bien ses vérifications de cohérence/intégrité côté serveur
que de donner la réponse à la question précise qu'il pose, surtout qu'on
s'en fiche clairement pour cette vérification là (je veux dire par là
que faite côté client ou serveur, on s'en tape pour une confirmation de
saisie). En ce sens, oui, ma réponse était à défaut de hors sujet, hors
question. Dans ce sens, on peut par exemple lire qu'il ne faut pas
changer le niveau d'erreur pour ne plus afficher les warnings mais
corriger le code, et c'est très bien. C'est ça que j'appelle "élever le
débat".

Ceci bien-sûr, si, comme je l'avais compris, le premier interrogateur avait juste
besoin de vérifier que l'utilisateur ne se trompe pas de mot de passe lors d'une inscription.

C'était en effet la question à la base et j'en ai profité pour en
remettre une couche sur les priorités dans l'intégrité des données.

a++
JG

A ce sujet, et pour répondre publiquement (déjà fait en privé) à
Davel_x, un paragraphe a été ajouté à la FAQ de ce forum détaillant le
fonctionnement de header() : http://faqfclphp.free.fr/#ss2.11

en parlant de la FAQ, les 2 liens :
http://aldev0.virtualave.net/php-perl-benchmarks.html
http://www.chamas.com/bench/hello_bysystem.html

a la fin de celle-ci ne sont plus valides

--
freelance + web|system developer|designer
+ 32 496 26 75 76 + http://www.capsule.org

john gallet wrote:

A ce sujet, et pour répondre publiquement (déjà fait en privé) à
Davel_x, un paragraphe a été ajouté à la FAQ de ce forum détaillant le
fonctionnement de header() : http://faqfclphp.free.fr/#ss2.11

La description technique est une bonne chose, elle peut éviter à
certains de se méprendre sur la nature de la fonction, et de bien
signaler que ça veut dire faire un aller retour au navigateur.

Maintenant je trouve que les deux derniers paragraphes ne devraient pas
s'y trouver. "Par conséquent, n'utilisez pas header("Location:...")" est
une instruction claire et sans compromis.
Pourtant c'est uniquement une opinion basée sur un choix personnel de
l'application. Cette recommandation a ses raisons (expliquées plus haut)
mais l'optique inverse peut aussi se justifier. Là j'ai peur que ça
mélange l'objectif qui découle de la technique (les deux premiers
paragraphes) et le subjectif sur les choix à faire en conséquence (les
deux derniers).
Si tant est que vous souhaitez laisser là cette recommandation je pense
qu'il serait bien de l'accompagner d'un autre son de cloche, d'un
commentaire de quelqu'un qui les utilise fréquement, volontairement et
en connaissance de cause. Bref, la modérer un peu.


Personnellement je met souvent de telles redirections, volontairement.
Effectivement ça rajoute du délai et de la charge réseau, il y a des
compromis à faire quand la consommation des ressources devient gênante
pour le client ou le serveur mais de là à dire qu'il ne faut "pas" les
utiliser .. il y a un pas que je ne franchirai pas. J'ai l'impression
que la recommandation se concentre uniquement sur l'aspect performance
en oubliant les certains principes du modèle HTTP (notamment la relation
ressource/URI) ou aspects du modèle Web (les retours arrière du
navigateur, les bookmarks ...)

Je n'ai jamais considéré require() comme une alternative à une
redirection HTTP, et à mon avis ce n'en est pas une. (ceci dit, il ne
faut pas en abuser non plus : la redirection http n'est pas une
alternative à require() ;))


Je crois que cette discussion a déjà été menée en partie souvent ici
mais comme je vois que seul une opinion a été retranscrite dans la FAQ
je me permet de donner mes raisons pour le faire :

- Avoir plusieurs types de ressources sur une même URL peut gêner
l'utilisateur, notament dans sa gestion des bookmarks. Si un recherche
ne renvoie qu'un résultat et que dans ce cas on souhaite l'afficher
directement, il faut renvoyer l'utilisateur vers ce résultat et non
faire une inclusion sserveur. L'utilisateur aura alors l'url finale du
document, réutilisable, copiable ...

- Lorsque le formulaire ne donne pas de message de confirmation ou de
résultat dédié mais renvoie simplement sur la page standard d'affichage,
ce qu'il se passe c'est effectivement théoriquement un envoi ET une
lecture. Le script gérant l'envoi génère effectivement un renvoie vers
l'URL classique de lecture. Chaque URL/ressource son boulot.

- Quand je tiens à ce que l'affichage suivant une soumission de
formulaire fasse parti du flux normal de navigation, c'est à dire qu'on
puisse "revenir" en arrière avec le navigateur ou resaisir la même URL
sans risques de voir une ressoumission des mêmes données

- et encore probablement bien 5 ou 6 cas fréquents que je n'ai pas en tête.



La recommandation faite est d'autant plus gênante à mes yeux qu'elle
recommande l'utilisation de exit() après le require, ce qui met
directement en échec les register_shutdown(), auto_append_file et autres
procédures de fermeture/netoyage/statistique.

Si vous voulez que j'essaie de vous soumettre une ligne ou deux à
rajouter pour modérer un peu le "n'utilisez pas" je peux essayer de le
faire.

Re,

Maintenant je trouve que les deux derniers paragraphes ne devraient pas
s'y trouver. "Par conséquent, n'utilisez pas header("Location:...")" est
une instruction claire et sans compromis.

Ce paragraphe dont tu parles a été remanié retronqué 25 fois. Tu
remarqueras que le dernier paragraphe laisse tout à fait le choix. Donc
si tu préfères une autre formulation du paragraphe :
----
Par conséquent, n'utilisez pas header("Location:...") pour rediriger
entre deux scripts de votre site. Cela imposerait un aller-retour
inutile entre le serveur et le navigateur. Il est bien plus rapide
d'ajouter simplement dans le code php les instructions :
require("script2.php"); exit();
----
pour moi il n'y a aucun problème, je suis ouvert à toute suggestion. Par
exemple : "Par conséquent, réfléchissez bien avant d'utiliser..." etc...

paragraphes) et le subjectif sur les choix à faire en conséquence (les
deux derniers).
Subjectif subjectif, pas tant que ça, le vrai problème c'est que des

personnes qui savent ce qu'elles font en utilisant cette méthode, il n'y
en a pas des masses. Je préfère donc dire "ne le faites pas", ceux qui
passent outre cette forte recommandation le feront parce qu'ils sont
assez grands pour ne pas avoir besoin de lire une FAQ pour développer.

Si tant est que vous souhaitez laisser là cette recommandation je pense
qu'il serait bien de l'accompagner d'un autre son de cloche, d'un
commentaire de quelqu'un qui les utilise fréquement, volontairement et
en connaissance de cause. Bref, la modérer un peu.
Cf le dernier paragraphe.

que la recommandation se concentre uniquement sur l'aspect performance
en oubliant les certains principes du modèle HTTP (notamment la relation
ressource/URI) ou aspects du modèle Web (les retours arrière du
navigateur, les bookmarks ...)
Là on va rentrer dans ce que je considère comme un troll et qui n'a

clairement pas sa place dans une FAQ sur php.

Je n'ai jamais considéré require() comme une alternative à une
redirection HTTP, et à mon avis ce n'en est pas une. (ceci dit, il ne
faut pas en abuser non plus : la redirection http n'est pas une
alternative à require() ;))
Ca n'a en à voir. Quand on reçoit des données, algorithmiquement, il y a

deux cas :
- si les données sont incomplètes ou incohérentes, générer le
forumulaire, fin.
- sinon, traiter les donnéees.

SI tu vois une redirection là dedans, moi pas.

Je crois que cette discussion a déjà été menée en partie souvent ici
mais comme je vois que seul une opinion a été retranscrite dans la FAQ
je me permet de donner mes raisons pour le faire :
Non, je me suis fait chier à passer 1/2 heure sur google à reparcourrir

les threads sur le sujet et ce que tu dis là n'a jamais été cité (sauf
le coup du refresh, j'ai un doute)

- Avoir plusieurs types de ressources sur une même URL peut gêner
l'utilisateur, notament dans sa gestion des bookmarks.
Quoi que ce soit que tu bookmarkes, les arguments seront bookmarkés

aussi donc ce sera pareil.

Si un recherche
ne renvoie qu'un résultat et que dans ce cas on souhaite l'afficher
directement, il faut renvoyer l'utilisateur vers ce résultat et non
faire une inclusion sserveur. L'utilisateur aura alors l'url finale du
document, réutilisable, copiable ...
Ok,cas particulier recevable, même si la seule et unique différence est

que dans un premier cas on referra la recherche, pas dans l'autre.

- Lorsque le formulaire ne donne pas de message de confirmation ou de
résultat dédié mais renvoie simplement sur la page standard d'affichage,
ce qu'il se passe c'est effectivement théoriquement un envoi ET une
lecture. Le script gérant l'envoi génère effectivement un renvoie vers
l'URL classique de lecture. Chaque URL/ressource son boulot.
(j'ai pas compris)

- Quand je tiens à ce que l'affichage suivant une soumission de
formulaire fasse parti du flux normal de navigation, c'est à dire qu'on
puisse "revenir" en arrière avec le navigateur ou resaisir la même URL
sans risques de voir une ressoumission des mêmes données
Pas compris non plus. Si tu ressaisis, tu fais une nouvelle requête de

toutes façons.

- et encore probablement bien 5 ou 6 cas fréquents que je n'ai pas en tête.
Moi non plus :-)

La recommandation faite est d'autant plus gênante à mes yeux qu'elle
recommande l'utilisation de exit() après le require, ce qui met
directement en échec les register_shutdown(), auto_append_file et autres
procédures de fermeture/netoyage/statistique.
S'il y a bien un truc que je ne recommenderai pas, c'est bien l'usage de

ce genre de trucs en automatique de toutes façons. A vérifier d'ailleurs
si exit shunte tout ça. Perso j'ai des scripts autonomes qui ne
dépendent pas de la configuration locale.

Si vous voulez que j'essaie de vous soumettre une ligne ou deux à
rajouter pour modérer un peu le "n'utilisez pas" je peux essayer de le
faire.

Fais toi plaisir, mais n'oublie pas le but d'une FAQ : éviter aux
newbies les conneries majeures, et l'abus de header:location en est
clairement une.

a++
JG