J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et
confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes champs
dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute
sur la confirmation du mot de passe. Comment dire "si le mot de passe est
différent de sa confirmation" alors on affiche une erreur ? la vérif
doit-elle se faire dans le fla ou dans le fichier PHP ?
Merci d'avance pour vos lanternes (je débute et j'essaye de comprendre au
fur et à mesure)
surtout pas dans le fla !! le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de passe apparaitrais en clair pour qui voudrait se donner la peine de le chercher !!! En fait, il faut faire comme pour un bête formulaire html, envoyer une requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur "valider". Pas d'autres moyens donc que de charger une nouvelle page ou au moins partie de page.
Lascap
surtout pas dans le fla !!
le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de
passe apparaitrais en clair pour qui voudrait se donner la peine de le
chercher !!!
En fait, il faut faire comme pour un bête formulaire html, envoyer une
requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de
passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur
"valider". Pas d'autres moyens donc que de charger une nouvelle page ou au
moins partie de page.
surtout pas dans le fla !! le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de passe apparaitrais en clair pour qui voudrait se donner la peine de le chercher !!! En fait, il faut faire comme pour un bête formulaire html, envoyer une requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur "valider". Pas d'autres moyens donc que de charger une nouvelle page ou au moins partie de page.
Lascap
Savut
Flash serait mieux, car tu soumet seulement quand c'est correct. Si tu le fait avec php, tu va devoir envoyer les 2 valeurs pour que php puisse valider ca et c'est une etape inutile.
Savut
"webmaster33" wrote in message news:bvqtu2$k5n$
Bonjour,
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes champs dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute sur la confirmation du mot de passe. Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
Merci d'avance pour vos lanternes (je débute et j'essaye de comprendre au fur et à mesure)
Flash serait mieux, car tu soumet seulement quand c'est correct. Si tu le fait avec php, tu va devoir envoyer les 2 valeurs pour
que php puisse valider ca et c'est une etape inutile.
Savut
"webmaster33" <sabsurf33@hotmail.com> wrote in message news:bvqtu2$k5n$1@news-reader3.wanadoo.fr...
Bonjour,
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et
confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes champs
dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute
sur la confirmation du mot de passe. Comment dire "si le mot de passe est
différent de sa confirmation" alors on affiche une erreur ? la vérif
doit-elle se faire dans le fla ou dans le fichier PHP ?
Merci d'avance pour vos lanternes (je débute et j'essaye de comprendre au
fur et à mesure)
Flash serait mieux, car tu soumet seulement quand c'est correct. Si tu le fait avec php, tu va devoir envoyer les 2 valeurs pour que php puisse valider ca et c'est une etape inutile.
Savut
"webmaster33" wrote in message news:bvqtu2$k5n$
Bonjour,
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes champs dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute sur la confirmation du mot de passe. Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
Merci d'avance pour vos lanternes (je débute et j'essaye de comprendre au fur et à mesure)
Thibaut Allender
sur la confirmation du mot de passe. Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
dans le fla je dirais, pour eviter d'envoyer des données inutilement au php, puisqu'elles ne sont pas valides si la confirmation ne correspond pas
sinon, euh, pour tester, je vois pas ou est la difficulté ?
un truc genre :
if ($pass != $confirmation) echo "le mot de passe et sa confirmation sont differents";
sur la confirmation du mot de passe. Comment dire "si le mot de passe est
différent de sa confirmation" alors on affiche une erreur ? la vérif
doit-elle se faire dans le fla ou dans le fichier PHP ?
dans le fla je dirais, pour eviter d'envoyer des données inutilement au
php, puisqu'elles ne sont pas valides si la confirmation ne correspond pas
sinon, euh, pour tester, je vois pas ou est la difficulté ?
un truc genre :
if ($pass != $confirmation) echo "le mot de passe et sa confirmation
sont differents";
sur la confirmation du mot de passe. Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
dans le fla je dirais, pour eviter d'envoyer des données inutilement au php, puisqu'elles ne sont pas valides si la confirmation ne correspond pas
sinon, euh, pour tester, je vois pas ou est la difficulté ?
un truc genre :
if ($pass != $confirmation) echo "le mot de passe et sa confirmation sont differents";
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes champs
dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute sur la confirmation du mot de passe.
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ? Ou est-ce qu'il y a des gens dans l'assemblée qui ne sont pas encore au courant que n'importe qui peut envoyer n'importe quoi à n'importe quel script du moment qu'il est public ?
Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
Vérifier si la saisie de deux champs est identique peut en effet se faire côté client. Ca n'a que très peu d'intérêt mais ça peut. Donc si tu sais faire en flash et que ça prend deux lignes, fais le en flash. Sinon ça te prendra une ligne de test dans la zone "tests d'incohérence" de ta gestion de réception du formulaire côté serveur.
a++ JG
Bonjour,
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et
confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes
champs
dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute
sur la confirmation du mot de passe.
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce
vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ?
Ou est-ce qu'il y a des gens dans l'assemblée qui ne sont pas encore au
courant que n'importe qui peut envoyer n'importe quoi à n'importe quel
script du moment qu'il est public ?
Comment dire "si le mot de passe est
différent de sa confirmation" alors on affiche une erreur ? la vérif
doit-elle se faire dans le fla ou dans le fichier PHP ?
Vérifier si la saisie de deux champs est identique peut en effet se faire
côté client. Ca n'a que très peu d'intérêt mais ça peut. Donc si tu sais
faire en flash et que ça prend deux lignes, fais le en flash. Sinon ça te
prendra une ligne de test dans la zone "tests d'incohérence" de ta gestion
de réception du formulaire côté serveur.
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et confirmation du mot de passe. J'ai déjà fait pas mal de vérif sur mes champs
dans mon .fla (longueur, champ vide, caractère spéciaux etc.) mais je bute sur la confirmation du mot de passe.
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ? Ou est-ce qu'il y a des gens dans l'assemblée qui ne sont pas encore au courant que n'importe qui peut envoyer n'importe quoi à n'importe quel script du moment qu'il est public ?
Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
Vérifier si la saisie de deux champs est identique peut en effet se faire côté client. Ca n'a que très peu d'intérêt mais ça peut. Donc si tu sais faire en flash et que ça prend deux lignes, fais le en flash. Sinon ça te prendra une ligne de test dans la zone "tests d'incohérence" de ta gestion de réception du formulaire côté serveur.
a++ JG
Savut
avec flash tu peux aussi bien faire un post ou get dans le background sans changer ou reload la page. Tout comme Java applet peut le faire.
Savut
"Lascap" wrote in message news:402126a6$0$15410$
surtout pas dans le fla !! le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de passe apparaitrais en clair pour qui voudrait se donner la peine de le chercher !!! En fait, il faut faire comme pour un bête formulaire html, envoyer une requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur "valider". Pas d'autres moyens donc que de charger une nouvelle page ou au moins partie de page.
Lascap
avec flash tu peux aussi bien faire un post ou get dans le background sans changer ou reload la page. Tout comme Java applet peut le
faire.
Savut
"Lascap" <lascap_PASDSPAMSVP_@olasia.org> wrote in message news:402126a6$0$15410$afc38c87@news.easynet.fr...
surtout pas dans le fla !!
le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de
passe apparaitrais en clair pour qui voudrait se donner la peine de le
chercher !!!
En fait, il faut faire comme pour un bête formulaire html, envoyer une
requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de
passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur
"valider". Pas d'autres moyens donc que de charger une nouvelle page ou au
moins partie de page.
avec flash tu peux aussi bien faire un post ou get dans le background sans changer ou reload la page. Tout comme Java applet peut le faire.
Savut
"Lascap" wrote in message news:402126a6$0$15410$
surtout pas dans le fla !! le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de passe apparaitrais en clair pour qui voudrait se donner la peine de le chercher !!! En fait, il faut faire comme pour un bête formulaire html, envoyer une requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur "valider". Pas d'autres moyens donc que de charger une nouvelle page ou au moins partie de page.
Lascap
m-e-
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ?
Non, pas toutes les vérifications. Seulement celles qui peuvent engendrer des problèmes de sécurité ou de validité des données, ou bien qui ne peuvent pas être faite côté client. Dans ce cas, la vérification n'est là que pour permettre au client de ne pas se tromper dans le choix du mot de passe (parce qu'on ne peut pas relire les champs mdp). Rien à voir avec les points (sensibles) précédents.
Ou est-ce qu'il y a des gens dans l'assemblée qui ne sont pas encore au courant que n'importe qui peut envoyer n'importe quoi à n'importe quel script du moment qu'il est public ?
S'amuser à modifier les variables de la requête pour faire en sorte que le mdp et sa confirmation soient différents n'aurait aucune utilité.
Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
Vérifier si la saisie de deux champs est identique peut en effet se faire côté client. Ca n'a que très peu d'intérêt mais ça peut.
Non, faire la vérification côté serveur et ne pas la faire côté client serait en l'occurence une perte de temps et de ressources, comme déjà dit. De plus, encore une fois, faire la vérification des deux côtés me semble dans ce cas inutile. Une vérification côté client est simple à mettre en oeuvre et suffisante.
Donc si tu sais faire en flash et que ça prend deux lignes, fais le en flash. Sinon ça te prendra une ligne de test dans la zone "tests d'incohérence" de ta gestion de réception du formulaire côté serveur.
On peut parler de logique. Certains préfèreront centraliser les manipulations de données sur le serveur. Pour ma part, je préfère un juste partage des tâches.
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce
vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ?
Non, pas toutes les vérifications. Seulement celles qui peuvent engendrer des problèmes de sécurité ou de validité des données, ou
bien qui ne peuvent pas être faite côté client.
Dans ce cas, la vérification n'est là que pour permettre au client de ne pas se tromper dans le choix du mot de passe (parce qu'on
ne peut pas relire les champs mdp). Rien à voir avec les points (sensibles) précédents.
Ou est-ce qu'il y a des gens dans l'assemblée qui ne sont pas encore au
courant que n'importe qui peut envoyer n'importe quoi à n'importe quel
script du moment qu'il est public ?
S'amuser à modifier les variables de la requête pour faire en sorte que le mdp et sa confirmation soient différents n'aurait aucune
utilité.
Comment dire "si le mot de passe est
différent de sa confirmation" alors on affiche une erreur ? la vérif
doit-elle se faire dans le fla ou dans le fichier PHP ?
Vérifier si la saisie de deux champs est identique peut en effet se faire
côté client. Ca n'a que très peu d'intérêt mais ça peut.
Non, faire la vérification côté serveur et ne pas la faire côté client serait en l'occurence une perte de temps et de ressources,
comme déjà dit.
De plus, encore une fois, faire la vérification des deux côtés me semble dans ce cas inutile.
Une vérification côté client est simple à mettre en oeuvre et suffisante.
Donc si tu sais
faire en flash et que ça prend deux lignes, fais le en flash. Sinon ça te
prendra une ligne de test dans la zone "tests d'incohérence" de ta gestion
de réception du formulaire côté serveur.
On peut parler de logique. Certains préfèreront centraliser les manipulations de données sur le serveur. Pour ma part, je préfère un
juste partage des tâches.
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ?
Non, pas toutes les vérifications. Seulement celles qui peuvent engendrer des problèmes de sécurité ou de validité des données, ou bien qui ne peuvent pas être faite côté client. Dans ce cas, la vérification n'est là que pour permettre au client de ne pas se tromper dans le choix du mot de passe (parce qu'on ne peut pas relire les champs mdp). Rien à voir avec les points (sensibles) précédents.
Ou est-ce qu'il y a des gens dans l'assemblée qui ne sont pas encore au courant que n'importe qui peut envoyer n'importe quoi à n'importe quel script du moment qu'il est public ?
S'amuser à modifier les variables de la requête pour faire en sorte que le mdp et sa confirmation soient différents n'aurait aucune utilité.
Comment dire "si le mot de passe est différent de sa confirmation" alors on affiche une erreur ? la vérif doit-elle se faire dans le fla ou dans le fichier PHP ?
Vérifier si la saisie de deux champs est identique peut en effet se faire côté client. Ca n'a que très peu d'intérêt mais ça peut.
Non, faire la vérification côté serveur et ne pas la faire côté client serait en l'occurence une perte de temps et de ressources, comme déjà dit. De plus, encore une fois, faire la vérification des deux côtés me semble dans ce cas inutile. Une vérification côté client est simple à mettre en oeuvre et suffisante.
Donc si tu sais faire en flash et que ça prend deux lignes, fais le en flash. Sinon ça te prendra une ligne de test dans la zone "tests d'incohérence" de ta gestion de réception du formulaire côté serveur.
On peut parler de logique. Certains préfèreront centraliser les manipulations de données sur le serveur. Pour ma part, je préfère un juste partage des tâches.
m-e-
surtout pas dans le fla !! le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de passe apparaitrais en clair pour qui voudrait se donner la peine de le chercher !!!
Je crois que webmaster33 voulait parler d'inscription, pas d'authentification.
En fait, il faut faire comme pour un bête formulaire html, envoyer une requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur "valider". Pas d'autres moyens donc que de charger une nouvelle page ou au moins partie de page.
Lascap
surtout pas dans le fla !!
le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de
passe apparaitrais en clair pour qui voudrait se donner la peine de le
chercher !!!
Je crois que webmaster33 voulait parler d'inscription, pas d'authentification.
En fait, il faut faire comme pour un bête formulaire html, envoyer une
requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de
passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur
"valider". Pas d'autres moyens donc que de charger une nouvelle page ou au
moins partie de page.
surtout pas dans le fla !! le flash a beau etre compilé, il peut être décompilé, et du coup ton mot de passe apparaitrais en clair pour qui voudrait se donner la peine de le chercher !!!
Je crois que webmaster33 voulait parler d'inscription, pas d'authentification.
En fait, il faut faire comme pour un bête formulaire html, envoyer une requete POST (techniquement on peux faire du GET, aussi, mais bon, le mot de passe dans l'url, moyen...) au serveur, au moment ou le type cliquer sur "valider". Pas d'autres moyens donc que de charger une nouvelle page ou au moins partie de page.
Lascap
m-e-
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et confirmation du mot de passe.
Je crois que tu veux parler d'inscription plutôt que d'authentification. Ou alors, inutile de mettre un champ de confirmation.
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et
confirmation du mot de passe.
Je crois que tu veux parler d'inscription plutôt que d'authentification. Ou alors, inutile de mettre un champ de confirmation.
J'ai un formulaire d'authentification FLASH/PHP avec login, mot de passe et confirmation du mot de passe.
Je crois que tu veux parler d'inscription plutôt que d'authentification. Ou alors, inutile de mettre un champ de confirmation.
john gallet
Bonjour,
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ? Non, pas toutes les vérifications. Seulement celles qui peuvent engendrer des problèmes de sécurité ou de validité des données, ou
bien qui ne peuvent pas être faite côté client.
Il me semble que le "non" est de trop. L'auteur de l'article dixit :"(longueur, champ vide, caractère spéciaux etc.)" en parlant de login/mot de passe donc cette remarque s'applique bien à une qui peut "engendrer des problèmes de sécurité ou de validité des données".
Dans ce cas, la vérification n'est là que pour permettre au client de ne pas se tromper dans le choix du mot de passe (parce qu'on ne peut pas relire les champs mdp). Rien à voir avec les points (sensibles) précédents. N'est-ce pas ce que je dis deux lignes en dessous ?
Vérifier si la saisie de deux champs est identique peut en effet se faire côté client. Ca n'a que très peu d'intérêt mais ça peut. Non, faire la vérification côté serveur et ne pas la faire côté client serait en l'occurence une perte de temps et de ressources,
comme déjà dit.
Comme déjà dit certes, mais quand je lis des âneries j'ai la faiblesse de les signaler à leurs auteurs.
1) Coût en ressources si on transmet la variable de deuxième saisie du mot de passe : - le nom de la variable : < 10 chars. - sa valeur : < 10 chars. Allez comptons large : 20 chars. - côté serveur : filtrer une variable de plus avec la fonction ad hoc, faire un test if($mdp1!=$mdp2).
2) coût en ressources en le faisant côté client : - envoi du script faisant le test et l'affichage du message d'erreur. Si tu arrives à faire ça en moins de 20 chars, j'en applaudirai des deux nageoires, promis.
Tout ce que tu peux gagner c'est éventuellement un aller-retour complet en cas d'erreur de saisie. Sur 100 personnes inscrites, à voir donc ce qui est gagné ou perdu. Je maintiens donc : "Ca n'a que très peu d'intérêt mais ça peut."
De plus, encore une fois, faire la vérification des deux côtés me semble dans ce cas inutile. Qui à part toi a dit qu'il fallait la faire des deux côtés ?
Une vérification côté client est simple à mettre en oeuvre et suffisante.
Une vérification côté serveur est encore plus simple et tout aussi suffisante, non nécessaire nous sommes bien d'accord si le client l'a déjà fait (cas dans lequel on ne transmet même pas la saisie de confirmation).
On peut parler de logique. Certains préfèreront centraliser les manipulations de données sur le serveur. Pour ma part, je préfère un juste partage des tâches.
Rares sont les vérifications de cohérence qu'il suffit de faire côté client. Très nombreuses sont les vérifications qui doivent impérativement être (re)faites côté serveur. Si tu commences par tout faire côté serveur tu es blindé. Et quand tout le monde en sera à optimiser ses transmissions de données et l'économie du transit des variables parce tout le reste est au cordeau, on en reparlera. Surtout que la plupart du temps, les mêmes braves gens qui "économisent des ressources" collent sans sourciller des appels à header:location dans tous les coins, ce qui a le don de me faire bien rigoler.
a++ JG
Bonjour,
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce
vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ?
Non, pas toutes les vérifications. Seulement celles qui peuvent engendrer des problèmes de sécurité ou de validité des données, ou
bien qui ne peuvent pas être faite côté client.
Il me semble que le "non" est de trop. L'auteur de l'article dixit
:"(longueur, champ vide, caractère spéciaux etc.)" en parlant de
login/mot de passe donc cette remarque s'applique bien à une qui peut
"engendrer des problèmes de sécurité ou de validité des données".
Dans ce cas, la vérification n'est là que pour permettre au client de ne pas se tromper dans le choix du mot de passe (parce qu'on
ne peut pas relire les champs mdp). Rien à voir avec les points (sensibles) précédents.
N'est-ce pas ce que je dis deux lignes en dessous ?
Vérifier si la saisie de deux champs est identique peut en effet se faire
côté client. Ca n'a que très peu d'intérêt mais ça peut.
Non, faire la vérification côté serveur et ne pas la faire côté client serait en l'occurence une perte de temps et de ressources,
comme déjà dit.
Comme déjà dit certes, mais quand je lis des âneries j'ai la faiblesse
de les signaler à leurs auteurs.
1) Coût en ressources si on transmet la variable de deuxième saisie du
mot de passe :
- le nom de la variable : < 10 chars.
- sa valeur : < 10 chars.
Allez comptons large : 20 chars.
- côté serveur : filtrer une variable de plus avec la fonction ad hoc,
faire un test if($mdp1!=$mdp2).
2) coût en ressources en le faisant côté client :
- envoi du script faisant le test et l'affichage du message d'erreur. Si
tu arrives à faire ça en moins de 20 chars, j'en applaudirai des deux
nageoires, promis.
Tout ce que tu peux gagner c'est éventuellement un aller-retour complet
en cas d'erreur de saisie. Sur 100 personnes inscrites, à voir donc ce
qui est gagné ou perdu. Je maintiens donc : "Ca n'a que très peu
d'intérêt mais ça peut."
De plus, encore une fois, faire la vérification des deux côtés me semble dans ce cas inutile.
Qui à part toi a dit qu'il fallait la faire des deux côtés ?
Une vérification côté client est simple à mettre en oeuvre et suffisante.
Une vérification côté serveur est encore plus simple et tout aussi
suffisante, non nécessaire nous sommes bien d'accord si le client l'a
déjà fait (cas dans lequel on ne transmet même pas la saisie de
confirmation).
On peut parler de logique. Certains préfèreront centraliser les manipulations de données sur le serveur. Pour ma part, je préfère un
juste partage des tâches.
Rares sont les vérifications de cohérence qu'il suffit de faire côté
client. Très nombreuses sont les vérifications qui doivent
impérativement être (re)faites côté serveur. Si tu commences par tout
faire côté serveur tu es blindé. Et quand tout le monde en sera à
optimiser ses transmissions de données et l'économie du transit des
variables parce tout le reste est au cordeau, on en reparlera. Surtout
que la plupart du temps, les mêmes braves gens qui "économisent des
ressources" collent sans sourciller des appels à header:location dans
tous les coins, ce qui a le don de me faire bien rigoler.
Nous sommes bien d'accord que DE TOUTES FACONS il ***FAUT*** faire ce vérifications aussi dans le script PHP qui reçoit ces données n'est-ce pas ? Non, pas toutes les vérifications. Seulement celles qui peuvent engendrer des problèmes de sécurité ou de validité des données, ou
bien qui ne peuvent pas être faite côté client.
Il me semble que le "non" est de trop. L'auteur de l'article dixit :"(longueur, champ vide, caractère spéciaux etc.)" en parlant de login/mot de passe donc cette remarque s'applique bien à une qui peut "engendrer des problèmes de sécurité ou de validité des données".
Dans ce cas, la vérification n'est là que pour permettre au client de ne pas se tromper dans le choix du mot de passe (parce qu'on ne peut pas relire les champs mdp). Rien à voir avec les points (sensibles) précédents. N'est-ce pas ce que je dis deux lignes en dessous ?
Vérifier si la saisie de deux champs est identique peut en effet se faire côté client. Ca n'a que très peu d'intérêt mais ça peut. Non, faire la vérification côté serveur et ne pas la faire côté client serait en l'occurence une perte de temps et de ressources,
comme déjà dit.
Comme déjà dit certes, mais quand je lis des âneries j'ai la faiblesse de les signaler à leurs auteurs.
1) Coût en ressources si on transmet la variable de deuxième saisie du mot de passe : - le nom de la variable : < 10 chars. - sa valeur : < 10 chars. Allez comptons large : 20 chars. - côté serveur : filtrer une variable de plus avec la fonction ad hoc, faire un test if($mdp1!=$mdp2).
2) coût en ressources en le faisant côté client : - envoi du script faisant le test et l'affichage du message d'erreur. Si tu arrives à faire ça en moins de 20 chars, j'en applaudirai des deux nageoires, promis.
Tout ce que tu peux gagner c'est éventuellement un aller-retour complet en cas d'erreur de saisie. Sur 100 personnes inscrites, à voir donc ce qui est gagné ou perdu. Je maintiens donc : "Ca n'a que très peu d'intérêt mais ça peut."
De plus, encore une fois, faire la vérification des deux côtés me semble dans ce cas inutile. Qui à part toi a dit qu'il fallait la faire des deux côtés ?
Une vérification côté client est simple à mettre en oeuvre et suffisante.
Une vérification côté serveur est encore plus simple et tout aussi suffisante, non nécessaire nous sommes bien d'accord si le client l'a déjà fait (cas dans lequel on ne transmet même pas la saisie de confirmation).
On peut parler de logique. Certains préfèreront centraliser les manipulations de données sur le serveur. Pour ma part, je préfère un juste partage des tâches.
Rares sont les vérifications de cohérence qu'il suffit de faire côté client. Très nombreuses sont les vérifications qui doivent impérativement être (re)faites côté serveur. Si tu commences par tout faire côté serveur tu es blindé. Et quand tout le monde en sera à optimiser ses transmissions de données et l'économie du transit des variables parce tout le reste est au cordeau, on en reparlera. Surtout que la plupart du temps, les mêmes braves gens qui "économisent des ressources" collent sans sourciller des appels à header:location dans tous les coins, ce qui a le don de me faire bien rigoler.
a++ JG
Davel_x
"john gallet" a écrit dans le message de news: Surtout | que la plupart du temps, les mêmes braves gens qui "économisent des | ressources" collent sans sourciller des appels à header:location dans | tous les coins, ce qui a le don de me faire bien rigoler.
ça bouffe tant de ressources que ça les header(location:) ?? ça m'inquiète car j'en utilise pas mal. Y'as un moyen de savoir ce qui bouffe ou pas de la ressource dans les fonctions php ? là par exemple je m'en doutais pas...
-- **davel_x** http://www.lerpg.com
"john gallet" <john.gallet@wanadoo.fr> a écrit dans le message de
news:402272D2.515D3A55@wanadoo.fr...
Surtout
| que la plupart du temps, les mêmes braves gens qui "économisent des
| ressources" collent sans sourciller des appels à header:location dans
| tous les coins, ce qui a le don de me faire bien rigoler.
ça bouffe tant de ressources que ça les header(location:) ?? ça m'inquiète
car j'en utilise pas mal. Y'as un moyen de savoir ce qui bouffe ou pas de la
ressource dans les fonctions php ?
là par exemple je m'en doutais pas...
"john gallet" a écrit dans le message de news: Surtout | que la plupart du temps, les mêmes braves gens qui "économisent des | ressources" collent sans sourciller des appels à header:location dans | tous les coins, ce qui a le don de me faire bien rigoler.
ça bouffe tant de ressources que ça les header(location:) ?? ça m'inquiète car j'en utilise pas mal. Y'as un moyen de savoir ce qui bouffe ou pas de la ressource dans les fonctions php ? là par exemple je m'en doutais pas...
