Bonjour à tous,
je viens à vous pour avoir votre opinion sur un petit débat qui fait rage entre mon chef et moi
Nous développons actuellement une application web PHP/Oracle avec utilisation de la méthode d'inclusion de fichiers (header, corps, footer...). Chaque écran (au sens métier) de notre application est généré par un script php au nom bien déterminé et donc inclus dans le corps via cette méthode. Nous détectons le fichier à inclure via les variables passées par URL (module=répertoire et page=script php). Voilà pour le contexte.

S'agissant des formulaires, j'avais pour habitude de préciser des variables dans l'URL par l'intermédiaire de l'attribut action du formulaire pour déterminer quel script sera appelé.
En gros le principe est que tout ce qui concerne la navigation et l'inclusion se fait par la méthode GET et tout ce qui constitue le coeur du métier et les données par la méthode POST.
Mais mon chef n'est pas de cet avis. Il me dit que mélanger les 2 méthodes dans un formulaire n'est pas bien (voir que cela ne fonctionne pas sous certains navigateurs) et qu'il faut passer ces informations par des champs cachés...
En gros la partie de mon code qui sert à détecter quel script appelé doit à la fois vérifier dans le GET et le POST...


J'aimerai avoir votre opinion la plus poussée possible.
Pour moi cela constitue un peu le passage obligé pour passer d'un developpement amateur à celui de professionnel (monde dans le quel je débute)

A titre perso, je n'aime pas cette méthode consistant à tout mettre dans une seule page par l'intermédiaire d'include.
Je préfère créer une nouvelle page à chaque fois.

Maintenant, avant de partir en querelle sur le bien fondé du POST et du GET, il faut avant tout prendre en compte 2 paramètres :
- l'utilisateur ;
- la sécurité.

Faire passer les données en post ne les rends pas visible dans l'URL (sécurité) mais ca empèche l'utilisateur de mettre une page donnée dans ses favoris.
Maintenant, à vous de voir ce qui est à privilégier.

Faire passer les données en post ne les rends pas visible dans l'URL (sécurité) mais ca empèche l'utilisateur de mettre une page donnée dans ses favoris.
Maintenant, à vous de voir ce qui est à privilégier.

> Faire passer les données en post ne les rends pas visible dans l'URL (sécurité)

J'espère que c'est une blague. Te rends-tu compte le l'enormité que tu as écris ? Passé les données par post n'améliore en rien la sécurité. Il n'y a pas besoin de faire un telnet ou d'utiliser curl pour simuler une requête post, il suffit de sauvegarder la page du formulaire et de modifier toutes les données que l'on veut et de la resoumettre.

Je rappelle que sans être parano, il ne faut faire confiance à aucune donnée ou information venant de l'internaute: que ce soit les données en GET, en POST, les données du genre navigateur, page précédente (referer), adresse IP, COOKIE,... Tout cela peut être aisément falsifié.

Mais mon chef n'est pas de cet avis. Il me dit que mélanger les 2 méthodes dans un formulaire n'est pas bien (voir que cela ne fonctionne pas sous certains navigateurs)

La partie concernant les navigateurs est évidemment fausse. En revanche, je suis plutôt d'accord que mélanger les deux peut-être source d'erreurs. Mais c'est tellement pratique; je le fais aussi pour différencier des formulaires.

et qu'il faut passer ces informations par des champs cachés... Sick
En gros la partie de mon code qui sert à détecter quel script appelé doit à la fois vérifier dans le GET et le POST...

Tu peux utiliser $_REQUEST qui mixe mes deux.

on va dire que le POST est un poil plus sécurisé que le GET, parce qu'il faut faire un peu plus de manipulations pour le forcer, - mais on est d'accord: il faut toujours tout vérifier venant du web!

Mélanger GET et POST, c'est vrai que ça fait pas terrible dans un formulaire, car l'attribut method ne permet qu'une seule des deux valeurs.

J'utilise le même genre d'architecture (psedu-frame) au boulot et ça donne:
- liens avec la page en GET
- formulaires entièrement en POST, y compris la page

La page qui gère ça vérifie la page en POST puis en GET, et ça marche très bien, sans être contraignant.

Pour moi cela constitue un peu le passage obligé pour passer d'un developpement amateur à celui de professionnel (monde dans le quel je débute)

Ce passage se fait, à mon avis par:
- du code moins crade (GET et POST en même temps?
- une séparation script / métier / présentation
- un codage objet
- un fichier de parametres le plus complet possible
- une classe SQL
- des tests lors de la conception (je vais y venir à SimpleTest! )
- une modélisation et de la documentation écrite (wiki )
- une installation et configuration de PHP sur le serveur (ça c'est le premier point en fait)
- ...

Bienvenue dans le monde des pros!

A+

Pascal

Avec l'extension Web Developper de Firefox par exemple, c'est vraiment très facile de modifier les champs hidden (Forms > Display Form Details).

Tout d'abord merci à tous pour vos réponses.

- du code moins crade (GET et POST en même temps?

nous avons en effet des formulaires dans la plupart de nos pages, mais mélanger les deux méthodes est un vieux réflexe issu des CMS (du moins ceux que je pratique)

- une séparation script / métier / présentation

hélas le temps nous manque et l'intéret d'utiliser des templates ne s'est pas fait ressentir....juste une trentaine d'écran constituent l'application intranet en cours de developpement.

- un codage objet

on essaie mais comme précédemment le temps nous manque alors on mélange les deux. Nous sommes quand meme en php 5.

- un fichier de parametres le plus complet possible

ça on a! on en a meme trop certainement.

- une classe SQL

On utilise ADOBD et on en est assez satisfait.

- des tests lors de la conception (je vais y venir à SimpleTest! )
- une modélisation et de la documentation écrite (wiki )
- une installation et configuration de PHP sur le serveur (ça c'est le premier point en fait)
- ...

La modélisation lors de l'étude générale et détaillée a été fait la plus sérieusement possible. La configuration est ok aussi.

Avec l'extension Web Developper de Firefox par exemple, c'est vraiment très facile de modifier les champs hidden (Forms > Display Form Details).

Ayé aussi !! d'ailleur je l'ai découvert que très récemment et franchement c'est génial!!

Je vais tacher d'utiliser $REQUEST aussi avec un bon extract bien configuré et ca devrait aller.

pascaltje, tu peux m'expliquer ton architecture pseudo-frame stp, j'ai pas top compris du moins, je ne vois pas trop comment tu fais.


Si nous avions eu le temps on serait parti d'un framework comme prado...mais en SSII ce n'est meme pas la peine.

Pour les pseudo frames:

Chaque écran (au sens métier) de notre application est généré par un script php au nom bien déterminé et donc inclus dans le corps via cette méthode. Nous détectons le fichier à inclure via les variables passées par URL (module=répertoire et page=script php). Voilà pour le contexte.

c'est ce que j'utilise: des liens du type index.php?page=pathto/page

index.php va tester diverses choses:
- l'utilisateur est-il enregistré ?
- a-t-il les droits d'accès à pathto/page.php ?
- la session n'a-t-elle pas expiré ?
- ...
et va aussi préparer les données:
- récupérations des données de session (unserialize)
- includes des fichiers de base (config, SQL, moteur de template ...)

le reste de l'architecture:
- des dossiers js, images, css qui contiennent ces types de fichiers
- un dossier classe qui contient les classes
- un dossier template qui contient les templates / modeles html de pages
- un dossier pages qui contient le script qui va construire chaque page

Le script de la page fait en gros 3 choses:
- déterminer quel traitement il doit effectuer (des if dans tous les sens qui initialisent $traitement)
- effectuer le traitement (switch/case % $traitement: plus lisible que de tout mélanger avec le point précédent)
- afficher la page (écran) correspondante

Le codage objet n'est pas une perte de temps.
En gros dans une appli intranet tapant une DB, on a spécifiquement pour un formulaire:
- récupérer les données du formulaire
- tester la validité des valeurs
- enregistrer les données: insertion ou mise à jour
- initialisation des valeurs (SELECT en DB)
- suppression de données

et c'est quasi le même pour tous les écrans/scripts. mes classes font ces fonctions de base, quand il faut faire plus, elles font plus. Le code du script utilise ces classes qui cachent le fonctionnement interne, - et cachent surtout beaucoup de lignes de code. ça rend le code + lisible qu'en procédural, plus court, plus simple à reprendre.

ex: on a ajouté un champ dans une table de la DB. ça veut dire une case en plus dans un formulaire. comment modifier ça?
- on va dans la classe, on modifie les 4-5 requetes en ajoutant ce champ
- on va dans le fichier template, on ajoute la case
- on va dans le script, on ajoute le parsing de la case dans la partie "afficher la page (écran)"
- parfois il y a des requetes qui se balladent dans le script, il faut aussi les vérifier

concretement on y gagne un max
il y a aussi moins de risques de tout casser car on travaille sur des parties relativement faiblement liées entre elles.

voilà voilà
convaincu?

A+

Pascal

Un ptit schéma ?

non non, pas de schéma: je dessine très mal

surtout un accès de flemme!

A+

Pascal

S'agissant des formulaires, j'avais pour habitude de préciser des variables dans l'URL par l'intermédiaire de l'attribut action du formulaire pour déterminer quel script sera appelé.
En gros le principe est que tout ce qui concerne la navigation et l'inclusion se fait par la méthode GET et tout ce qui constitue le coeur du métier et les données par la méthode POST.
Mais mon chef n'est pas de cet avis. Il me dit que mélanger les 2 méthodes dans un formulaire n'est pas bien (voir que cela ne fonctionne pas sous certains navigateurs) et qu'il faut passer ces informations par des champs cachés...
En gros la partie de mon code qui sert à détecter quel script appelé doit à la fois vérifier dans le GET et le POST...

Mon opinion ne va pas être extrèmement poussée puisqu'en ce qui concerne la méthodologie générale mes prédecesseurs ont tout dit Par contre en ce qui concerne les formulaires, j'ai le même raisonnement que toi, j'en suis arrivé à la même conclusion, et à la même méthode. Elle fonctionne très bien, n'est ni plus ni moins sécurisée qu'une autre, bien plus facile à gérer que les champs cachés (d'autant que les champs cachés sont parfois utilisés pour faire transiter d'autres données qu'un simple "whattodo", et on finit par tout mélanger), etc...

Je pense que ton chef a tort et le fait qu'il invoque une potentielle incompatibilité des navigateurs m'inquiète sur ses connaissances dans le domaine (même Lynx gère très bien le mélange GET/POST, c'est complètement standard).

Si l'on regarde du côté des standards édictés par le W3C sur le sujet (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html),
- la méthode GET doit être reservée à l'obtention de données et si l'on suit l'esprit de cette définition, le GET sert donc à identifier la page pour la navigation de l'utilisateur. Ainsi, les informations passant par l'URL ont vocation à permettre la selection de la page qui traiterera la requête utilisateur.
- la méthode POST doit être reservée à la soumission/envoi de données de l'utilisateur au serveur : poster un message, envoyer un document, etc.

Voilà, au niveau HTTP.
Maintenant si l'on applique ce concept à la soumission d'un formulaire, on voit que les paramètres passés dans l'URL auront vocation à correspondre à ce que fait le GET: identifier la page, la navigation tandis que les données du formulaire soumis avec la méthode POST se mappent sur une requete HTTP POST.

En conclustion, il n'y a aucun inconvénient à mélanger les 2 méthodes à la condition de respecter ce découpage et bien faire le traitement avec $_GET et $_POST (et non pas $_REQUEST, sous peine d'écrasement éventuel de variables homonymes et de mélange des genres)

Moi j'utilise GET uniquement pour circuler sur le site.
Pour tous le reste j'utilise POST.
Comme ca l'adresse web reste courte et propre.
Content de voir que c'est ce que preconise le W3c.

En effet, mais la réponse est plus riche: il est possible de mélanger les 2 modes en mettant dans l'action du formulaire des paramètres de type GET qui correspondent à la navigation tandis que les éléments contenus dans le formulaire soumis avec la méthode POST sont des données de traitement et non de navigation.