[resolu] Validation Automatique de Formulaire

Salut le monde

Validation automatique de formulaire
Je n'est pas la possibilite de passer des variables par l'url, donc me reste le formulaire.
et lorsque cela doit se faire apres un script, et doit entrainer une redirection.. ben j'ai trouver que cette solution.

attention ca fait mal aux yeux

<div style="height:100%; width:100%; background-color:RGB(255,255,255); z-index:99 ;position:absolute; top:0; left:0px;"></div>
<form name="redirect" action="societe.cfm" method="post">
  <input type="hidden" name="Id" value="25" />
  <input type="submit" height="0" width="0" />
</form>
<script language="JavaScript">document.redirect.submit();</script>  	

Le DIV sert a cacher le bouton submit qui est obligatoire pour que je javascript fonctionne.

bon, c'est tres laid, pas beau, pas bien.
mais qqun a trouver mieux déjà ?
plus simple ? Plus propre ?
Modifié par Lorr Hyde (25 Apr 2005 - 13:29)

Lorr Hyde a écrit :
mais qqun a trouver mieux déjà ?
plus simple ? Plus propre ?

Oui, j'ai toujours trouvé un moyen de passer les variables par l'URL (surtout un ID !).

Si tu nous faisais partager ce que tu souhaites faire, et ce qui t'empêche de passer les variables par URL, nous pourrions peut-être t'aider

ha mais passer une ID par l'URL c'est pas tres compliquer..
je me suis surement mal expliquer .

Donc .. passer une ID par l'URL, utilise le GET ,pas sur , pas forcement de rafrrechisement au serveur, et hack assez simple.

Autre solution, passer les variable par Post, et la pas de solution autre ( à ma connaissance) que le formulaire.

Donc soumition de formulaire automatique apres l'execution d'une requête, d'un script, ou d'une autre tache automatique ...

et j'ai trouve cette solution qui fonctionne mais resemble plus a du bricolage que de la rpogrammation.

et voilà, d'ou ma question de base ..

y a t'il quelque chose de mieux a faire ?

Lorr Hyde a écrit :
Donc .. passer une ID par l'URL, utilise le GET ,pas sur , pas forcement de rafrrechisement au serveur, et hack assez simple.

Qu'est-ce que tu entends par "rafrrechisement au serveur" ?

Ensuite, GET n'est pas plus "risqué" que POST ! Avec ta méthode actuelle, il me suffit de désactiver le JavaScript pour rester sur la page où se déroule le transfert, c'est-à-dire où se trouve le formulaire. À partir de là, ayant les noms des champs qu'utilisent ton formulaire, je peux très bien re-créer un formulaire moi-même en modifiant la valeur.

Conclusion : POST est aussi risqué que GET !

De plus, s'il suffit de modifier l'ID dans l'URL ou bien dans le formulaire pour pouvoir "tricher" sur ton site (ça dépend de ce que cela entraîne), alors c'est ton site qui est mal fait !

Sinon, il faut toujours faire une vérification. Par exemple pour l'id, il doit s'agir d'un chiffre. En PHP, on peut alors utiliser la fonction is_numeric() pour savoir si l'information n'a pas été falsifiée pour tentative de "piratage". Et si l'id est bien numérique, alors on peut sans problème faire l'opération demandée. Mais après, pour ne pas afficher ce que quelqu'un ne devrait pas voir, la sécurité se trouve dans les requêtes ou le code, mais en aucun cas dans l'ID !

Nyro Xeo a écrit :

Qu'est-ce que tu entends par "rafrechisement au serveur" ?

Conclusion : POST est aussi risqué que GET !

De plus, s'il suffit de modifier l'ID dans l'URL ou bien dans le formulaire pour pouvoir "tricher" sur ton site (ça dépend de ce que cela entraîne), alors c'est ton site qui est mal fait !

Par rafrechissement au serveur, j'entend que la valeur de la variable ne sera JAMAIS dans le cache de la machine du visiteur, au contraire de GET.

La différence entre GET et POST est suffisement grande pour qui s'y connais un peu pour voir les différences de sécurite entre les 2 systemes de passage de donnée.
De plus la limite de passage de donnée dans l URL est de 256 character (la longuer max d'une url) et elle est de 2MG avec POST.

Je t'assure que 'tricher' sur mon site ne tient pas que a cela.

Mais j'ai pas vraiment l'impression que tu t'interesse a ma question, mais plutot a étaler ta science (assez reduite visiblement).

Débat interessant qui ne répond pas a ma question.

Tu as réussi a faire un forumlaire auto validé avec du code plus propre ?
ou non.
Car l'objet de mon post c'est bien celui là.
Modifié par Lorr Hyde (22 Apr 2005 - 21:12)

Lorr Hyde, merci d'éviter d'enflammer négativement la conversation. Je ne crois pas que Nyro Xeo voulait étaler sa science. D'ailleurs, évite de porter un jugement sur sa "science", surtout si c'est dans le but de la sous-estimer.

Pour ma part, niveau sécurité, si on parle uniquement de validation de données, la méthode GET ou POST revient au même. Les seules différences au niveau sécurité est le fait que l'url reste souvent dans la Cache ou dans l'historique.

Pour répondre partiellement à ta question, déjà, change l'attribut language pour type :

<script type="text/javascript">...</script>

Le mieux serait aussi de mettre le code Javascript dans un fichier externe. Je n'ai malheureusement pas le temps de t'aider davantage, je me suis surtout arrêté parce que je sentais une certaine agressivité en toi.

Oh, pourrais-tu préciser pour quelle raison tu ne peux pas passer les données dans l'url, question qu'on comprenne bien ton objectif.
Modifié par Merkel (22 Apr 2005 - 22:22)

Lorr Hyde a écrit :
Mais j'ai pas vraiment l'impression que tu t'interesse a ma question, mais plutot a étaler ta science (assez reduite visiblement).

Non en vérité, je cherche à te faire comprendre que faire valider un formulaire automatiquement par du JavaScript juste pour bénéficier des avantages de la méthode POST est une erreur. Surtout lorsqu'il ne s'agit "que" d'un id.

Ton but est donc de cacher au mieux (pour la sécurité) les données transmises.

Et si on désactive le JavaScript ? Une méthode plus propre consisterait à faire un script valide (language="JavaScript" à supprimer, l'attribut name de <form> à remplacer par id, mettre des commentaires entre les balises <script> et </script>, mettre les champs entre balises de type bloc, et spécifier le bon type de <script>), mais ça n'enlève rien au fait que c'est une méthode sale.

Ce que j'appelle méthode propre, c'est une méthode où il n'y a pas besoin de cacher des informations, où tout est sécurisé "automatiquement" (si je puis dire).

Pour prendre un exemple similaire, ce serait comme vouloir cacher la source d'une page (enfin faut comprendre la subtilité/nuance).

Pour le cas d'un id, il s'agirait de vouloir sélectionner une entrée dans une base de donnée. Et très franchement, j'aimerais que tu me dises pourquoi tu veux cacher cet ID !

Concernant la phrase même :

Lorr Hyde a écrit :
Mais j'ai pas vraiment l'impression que tu t'interesse a ma question, mais plutot a étaler ta science (assez reduite visiblement).

...je trouve vraiment pathétique ce genre de réaction. J'essaie de t'aider en te faisant prendre conscience de l'absurdité de la méthode que tu veux utiliser. Je te donne quelques "conseils" pour pouvoir filtrer correctement l'id. Et toi, qu'est-ce que tu me sors ? Que je cherche à montrer ma connaissance et que celle-ci est très limitée...

Pour répondre dans ce sens même : ces propos impliquent simplement que ta "science" à toi est plus grande que la mienne ? Je ne veux pas dire que ce n'est pas le cas, mais à ta place, je me garderai d'émettre de tels propos, ne serait-ce que parce qu'on se trouve sur un forum public où l'ambiance se doit d'être agréable, mais aussi parce qu'il est évident que tu n'en sais rien, et que de vouloir insister dans la méthode du sujet prouve presque le contraire... Mais bref, passons !

a écrit :
La différence entre GET et POST est suffisement grande pour qui s'y connais un peu pour voir les différences de sécurite entre les 2 systemes de passage de donnée.

Eh bien le fait que tu exploites cette technologie en validant automatiquement un formulaire grâce à du JavaScript enlève toute sécurité !

a écrit :
De plus la limite de passage de donnée dans l URL est de 256 character (la longuer max d'une url) et elle est de 2MG avec POST.

Merci, j'étais au courant. Mais tu vas me dire que ton id fait plus de 256 caractères de long ? ^^

Si je te propose de passer simplement l'id par l'URL, c'est parce que "c'est fait pour" en quelques sortes.

a écrit :
Je t'assure que 'tricher' sur mon site ne tient pas que a cela.

Ah... D'autres failles en vue ? Oui bon là c'est vraiment pour t'embêter que je dis ça

a écrit :
Débat interessant qui ne répond pas a ma question.

Si tu faisais la part des choses, alors oui, cela répondrait à ta question.

bon bon bon bon ...

J'ai chercher et j'ai trouve
Bien fait pour moi.

Alors je commence par faire de plate excuse a Nyro Xeo.
scuse scuse scuse.

J'arrive a m'enflammer assez vite...

Bien.

Ce que je dévellope n'est pas une page web, mais une application.
Gestion ... ect.
Le nombre de paramêtre de sécurité a respecter est a pleurer, mais c'est bon, même en passant par l'URL pas de problème tu peut rien faire de mal.
pas de faille (ou les testeur on pas encore trouver).
Tout passait par la jusqu'a il y a 1 semaine.

les FORM avec redirection viennent derrière des Script qui s'execute sur le serveur apres des actions.

Malheureusement pour moi les variables en GET ne sont pas rafrechie sous certain processus, du genre va dont chercher des variables en get depuis un flash et tu verra le resultat su la variable change, le flash est dans le cache, et il concidere ne pas avoir besoin de redemander. pris en POST, pas de malèse, a chaque passage il les redemandent. (sous FF les variables get sont rafrechie aussi, mais pas IE). J'utilise pas de flash, mais c'est un exemple.
L'autre grand avantage des variables prise en POST est de les générer directement sur le serveur, et pas en 'client', et la y a pas photo.
le formulaire auto n'apparait jamais, il se trouve derriere un script qui tourne sur le serveur appres un appel depui une page.

Il ne sagit pas que d'un ID, mais il est vrai que cela tennait dans l'URL avant la découverte ce se problème de rafrechissement.

le problème de javascript désavtivé ne se pose pas , car les personne qui pourront utilise l'application n'auront pas vraiment le choix d'activé ou pas.
c'est obligatoire.

Si je trouvais ma methode correct, je ne serais pas venu sur se Forum pour demander si on peu pas faire mieux hein !

bon .. je m excuse encore une fois ?
allez encore une fois ..
m'excuse .....

Je voulais d'abord remercier Nyro Xeo d'avoir répondu de façon correcte et dans le calme, et aussi Lorr Hyde d'avoir eu le respect de s'excuser. Tout rentre dans l'ordre.

Je tenais quand même à ajouter ma propre réponse à certaines choses que tu as dis Lorr Hyde.

Lorr Hyde a écrit :

Le nombre de paramêtre de sécurité a respecter est a pleurer, mais c'est bon, même en passant par l'URL pas de problème tu peut rien faire de mal.
pas de faille (ou les testeur on pas encore trouver).

Ce que tu dois comprendre, c'est que si ton application peut être piratée en passant certaines valeurs dans l'url, comme du SQL Injection par exemple, elle sera tout autant vulnérable en POST. C'est le point important de la chose. Alors si tes testeurs n'ont pas trouvés de failles par l'url, y'en aura pas en POST, et vice-versa. Ca ne fait aucune différence.

Lorr Hyde a écrit :

Malheureusement pour moi les variables en GET ne sont pas rafrechie sous certain processus, du genre va dont chercher des variables en get depuis un flash et tu verra le resultat su la variable change, le flash est dans le cache, et il concidere ne pas avoir besoin de redemander. pris en POST, pas de malèse, a chaque passage il les redemandent.

Il doit bien y avoir moyen de préciser au fichier flash de ne pas se mettre en cache ? Dans ton cas, si c'est une page web, tu peux l'indiquer côté serveur ou directement dans l'entête du document que ce dernier ne doit pas aller en cache dans le navigateur. Sinon, il y a toujours la méthode brutale. Tu passe une variable supplémentaire dans l'url contenant une valeur aléatoire, basée sur la dateheure, ce qui force le rechargement de la page.

Lorr Hyde a écrit :

L'autre grand avantage des variables prise en POST est de les générer directement sur le serveur, et pas en 'client', et la y a pas photo.
le formulaire auto n'apparait jamais, il se trouve derriere un script qui tourne sur le serveur appres un appel depui une page.

Pour être honnête, j'ai pas trop compris ce que tu voulais dire par là.

Lorr Hyde a écrit :

le problème de javascript désavtivé ne se pose pas , car les personne qui pourront utilise l'application n'auront pas vraiment le choix d'activé ou pas.
c'est obligatoire.

Pourquoi oblige-tu le Javascript ? Tu as beaucoup de fonctionnalités qui dépendent de ca ? N'y aurait-il pas moyen de faire fonctionner ton application sans cela ? Personnellement, dans mes systèmes de gestion, le Javascript n'est là que pour faciliter l'usage, mais ce n'est plus obligatoire depuis que j'ai refais mes modules.

Lorr Hyde a écrit :

Si je trouvais ma methode correct, je ne serais pas venu sur se Forum pour demander si on peu pas faire mieux hein !

Dans un tel cas, il faut que tu sache qu'en posant une question, il faut s'attendre à remettre en question sa façon de faire. Il m'est arrivé souvent de demander comment coder quelque chose, et lorsque j'expliquais pourquoi je voulais ca, quelqu'un de plus expérimenté me faisait réaliser que j'étais complètement hors-champ. C'est fréquent, faut s'y attendre et ne pas s'emflammer même lorsqu'on a l'impression que l'autre nous prends pour un con. Heureusement, ce n'était pas le cas ici.

Bon, a+