Discussion :

[__fabrice]

salut à tous,

Je voudrai savoir ce que vous utilisez pour la validation d'une formulaire... une classe ?, un script ?, un créateur automatique ?

- J'ai essayé le package de PEAR, certes pas mal, mais faut installer PEAR et c'est pas toujours faisable. Il est bien, simple, mais le design n'est pas toujours flexible, du coup, c'est pas simple pour l'inclure dans un site .

- Les créateurs automatique, genre (http://phpforms.net), pas mal aussi, mais le code n'est pas forcement non plus tres propre. Et j'ai l'impression de ne rien maitriser

- Les classes toutes faites (a aller voir, par exemple ici ou ici), j'ai un faible pour çà, surtout si on veut rester en objet. C'est simple et il y a de grandes possiblitées, si c'est bien fait.

Donc, j'aimerai avoir votre avis, et surtout , ce que vous utilisez.

Merci
Fabrice

[siddh]

salut,
personnelement je préfère faire ma validation coté client pour éviter des aller retours pour rien.
Je me suis fais un objet qui me permet de valider mon formulaire et de controler certaines saisies en javascript.

[__fabrice]

oui, çà se défends comme point de vue
Pour ma part, je viens de découvrir ceci... a tester je pense

Fabrice

[Séb.]

Telle que je la vois moins la solution génèrera de HTML/JS et mieux ce sera.
Je m'orienterai donc vers ta 3e proposition, eg un Valkyrie ( http://pecl.php.net/package/Valkyrie ).
D'ailleurs je me demande ce que les ptits gars de chez Zend attendent pour spécifier une telle extension qui s'avère absolument nécessaire au développement web.

[siddh]

ben c est pas super dur de se le faire
ca doit etre pour ca ...

Effectivement certains sont réticents a l utilisation de javascript mais pourquoi attendre de reçevoir le formulaire sur le serveur pour s'apercevoir qu'il n'y a pas d'email ou que le nom n'est pas assez long ?

Apres il faut renvoyer les données.

De même il est rtes simple d'empecher de taper du texte dans un champ que l'on veut numérique.

A part une vérification sur de la logique métier (par exemple vérifier qu'une quantité commandée n'excede pas la quantité en stock), je ne voit pas l'intéret d'une validation php.

Meme si je sais que certains diront "oui mais y en a qui ont pas javascript", personnes auxquelles je répond qu'ils ont pas de chance si ils ne peuvent pas l'utiliser car ça change la vie d'une application web.

[Séb.]

ben c est pas super dur de se le faire
ca doit etre pour ca ...

J'ose espérer que Zend soutenu par la Communauté feraient mieux que moi
Et puis c'est toujours mieux d'avoir une API native officielle, reconnue, correctement documentée, performante, maintenue, etc. plutôt q'uun obscur script PHP bogué russo-polonais qu'on risque de perdre de vue au 1er changement de nom de domaine.

Effectivement certains sont réticents a l utilisation de javascript mais pourquoi attendre de reçevoir le formulaire sur le serveur pour s'apercevoir qu'il n'y a pas d'email ou que le nom n'est pas assez long ?

De toute manière il faut bien valider les données côté-serveur, donc àmha autant oublier la validation côté-client.

[siddh]

ben non on est pas obligé de les valider coté serveur si ca été fait coté client

[Séb.]

ben non on est pas obligé de les valider coté serveur si ca été fait coté client

Par le simple fait qu'une personne mal intentionnée puisse désactiver JS et passer outre la validation côté-client on doit valider côté-serveur.
Ou alors ton design t'autorise à avoir une BdD crade, mais bon.

[siddh]

tout depend dans quel contexte tu te place.

Si tu as beaucoup de controle a faire, un "vrai" fomulaire, tu developpe une application et pas un site avec un formulaire de contact.

Normalement tu doit savoir si tu as ou pas la possibilité de faire du javascript. Si tu peux, autant le faire. Sinon bien entendu ben tu valide coté serveur.

Apres qu'une personne parano ou malveillante desactive le javascript et elle se rendra vite compte que ca ne marche pas de toute manière.

[kankrelune]

ben c est pas super dur de se le faire
ca doit etre pour ca ...

J'ose espérer que Zend soutenu par la Communauté feraient mieux que moi
Et puis c'est toujours mieux d'avoir une API native officielle, reconnue, correctement documentée, performante, maintenue, etc. plutôt q'uun obscur script PHP bogué russo-polonais qu'on risque de perdre de vue au 1er changement de nom de domaine.

Moi je fais les deux... pourquoi... la validation coté client ne coute rien en perf vu que c'est coté client et pour moi ça tient plus à au confort d'utilisation (ça évite le rechargement de la page, etc) qu'a la sécurité... une fois les données receptionnées je les vérifies coté serveur car comme le dit seb le javascript peut être désactivé coté client et pour moi il y a bien d'autre vérification à faire avant le traitement des données chose que je ne veux pas laisser faire au javascript... .. .

Donc quand on peut faire les deux pourquoi se priver... .. .

@ tchaOo°

[siddh]

la validation coté client ne coute rien en perf vu que c'est coté client et pour moi tient plus à un confort d'utilisation (ça évite le rechergement de la page, etc)...

wala

une fois les données receptionnées je les vérifies coté serveur car comme le dit seb le javascript peut être désactivé coté client

effectivement dans un cas ou tu peux pas savoir si les gens l'ont ou pas, je suis partisant du double controle mais je me met un flag qui me permet de savoir si le javascript a fait ou pas son controle pour pas doubler inutilement.

et pour moi il y a bien d'autre vérification à faire avant le traitement des données chose que je ne veux pas laisser faire au javascript... .. .

c'est ce dont je parlais comme logique métier je suppose

C'est certes plus chiant de faire comme ça mais ça apporte un confort indéniable à l'utilisateur et ça c'est le plus important pour moi.
Je préfère coder 2 heures de plus pour faire gagner 30s à l'utilisateur.
C'est peut être bizarre mais bon, je suis un peu maso

De toute manière je génere un maximum de code, donc a l'arrivée ça me coute finalement moins de temps, mais ça c'est encore autre chose ...

[kankrelune]

C'est certes plus chiant de faire comme ça mais ça apporte un confort indéniable à l'utilisateur et ça c'est le plus important pour moi.
Je préfère coder 2 heures de plus pour faire gagner 30s à l'utilisateur.
C'est peut être bizarre mais bon, je suis un peu maso

Tout à fait d'accord avec toi... .. .

Moi je suis partisant de trois chose...

Sécurité : 2eme controle sur le serveur

Confort d'utilisation : controle coté client

Perf (rapidité d'execution) : ici rien à voir mais ça ne les entame pas non plus

@ tchaOo°

[GregPeck]

je suis partisant du double controle mais je me met un flag qui me permet de savoir si le javascript a fait ou pas son controle pour pas doubler inutilement. ...

Je ne suis pas d'accord avec toi la dessus, il faut considérer le javascript comme n'étant pas sur. C'est à dire que je peux très bien faire un POST vers ta page php avec soi disant le flags initialisé. On fait ce que l'on veux.

Et si tu ne fait pas le controle en php, on peux facilement faire croire au php que le controle à déjà été fait alors que ce n'est pas le cas.

Pour reprendre ton exemple, si un champ attend du numérique et que tu ne le vérifie pas en php, ca peux générer des erreurs de scripts si on tombe par exemple sur un or die(mysql_error()) qui pourrait donner un truc du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Error near "INSERT INTO bidule SET nombre=Truc envoyer en javasvcript"

Ce qui est une info très interessante quand tu cherche à hacker un serveur par exemple. En un seul test, on sais qu'il existe une table 'bidule' avec un champ 'nombre'. Et ne parlons pas des injection SQL possible...

Enfin tout ça pour dire que je suis pour faire une double vérification systématiquement...

[kankrelune]

je suis partisant du double controle mais je me met un flag qui me permet de savoir si le javascript a fait ou pas son controle pour pas doubler inutilement. ...

Je ne suis pas d'accord avec toi la dessus, il faut considérer le javascript comme n'étant pas sur. C'est à dire que je peux très bien faire un POST vers ta page php avec soi disant le flags initialisé. On fait ce que l'on veux.

Et si tu ne fait pas le controle en php, on peux facilement faire croire au php que le controle à déjà été fait alors que ce n'est pas le cas.

Pour reprendre ton exemple, si un champ attend du numérique et que tu ne le vérifie pas en php, ca peux générer des erreurs de scripts si on tombe par exemple sur un or die(mysql_error()) qui pourrait donner un truc du style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Error near "INSERT INTO bidule SET nombre=Truc envoyer en javasvcript"

Ce qui est une info très interessante quand tu cherche à hacker un serveur par exemple. En un seul test, on sais qu'il existe une table 'bidule' avec un champ 'nombre'. Et ne parlons pas des injection SQL possible...

Enfin tout ça pour dire que je suis pour faire une double vérification systématiquement...

+1

@ tchaOo°

[siddh]

mwé enfin ca depend comment c'est codé derrière ...

Personnellement, pour qu'un hacker me foute la merde dans mon code, il va falloir qu il s'accroche.
Meme en ayant les sources je ne suis pas certain qu'il comprenne tout.

Je ne me vante pas ou quoi que ce soit je tiens a le dire.

J'ai une architecture de code qui fais que si tu connais pas a fond la poo, smarty, xml, css et javascript, tu pourras rien faire.

J'utilise une gestion d'erreur personnalisée en me servant des exceptions.
Les traces qui pourraient m'interresser en tant que developpeur sont dans des fichiers de logs protégés, pas dans la source.

Depuis le debut j'essayes de vous faire comprendre que ça va etre différent pour moi selon si on developpe une "application web" ou un site dont on connais ni ne maitrise les visiteurs et leur matériel.

Dans ce deuxième cas, il faut bien evidemment miser sur le serveur avec un plus en convivialité sur le client.

Sinon, dans le cadre d'un intranet ou tu vas peut etre tomber sur 1 personne parmis 100 qui n'aura pas le jevascript, il faudra lui expliquer qu il faut le mettre en lui faisant comprendre que y a aucun risque pour lui et que sinon il pourra pas utiliser son outil de travail.

[GregPeck]

J'utilise une gestion d'erreur personnalisée en me servant des exceptions.
Les traces qui pourraient m'interresser en tant que developpeur sont dans des fichiers de logs protégés, pas dans la source.

Dans ce cas, en effet ca peux être valable, seulement je ne pense pas que tout le monde code comme toi.

Meme en ayant les sources je ne suis pas certain qu'il comprenne tout.

Je traine souvent sur un site de challenge de hack. Et bien il y a des challenges où tu as le code php en clair sous les yeux, tu sais qu'il y a une faille d'un certain type et pourtant pour la trouver, c'est coton! J'ai un exemple sous les yeux qui fait 9 lignes, j'ai mis un peu de temps à trouver la faille.

Enfin bref, moi je préfère ne faire confiance à personne, même pas à moi

[siddh]

oui je dis pas que mon code est infaillible loin de la certainement meme
mais c est clair que va falloir etre motivé pour me faire chier sans voir le code.

D'autant que si le mec a le code devant les yeux c'est deja trop tard ^^

[GregPeck]

D'autant que si le mec a le code devant les yeux c'est deja trop tard

C'est clair !

[siddh]

Je vais programmer un piège a loup dans mon htdocs

[sekaijin]

salut,
personnelement je préfère faire ma validation coté client pour éviter des aller retours pour rien.
Je me suis fais un objet qui me permet de valider mon formulaire et de controler certaines saisies en javascript.

Ne pouvant pas présager des capacité de tous les navigateurs la validation côté client ne peu pour moi qu'être un plus.

je fait donc les deux côté client et côté serveur.

de plus le client n'a pas pas toujours accès à tout les élément nécessaire pour valider la saisie.

par exemple dans la gestion des utilisateurs j'ai des groupes un groupe à un manager

dans le formulaire de création d'un groupe je peu côté client vérifier les types les dates mais il est impossible de vérifier que l'identifiant du manager est bien en base.

je fais donc des vérifications de type côté client et les mêmes plus quelques autres côté serveur.

A+JYT