Bonjour,
je me pose encore une question:
La vérification des données fournit par un formulaire html, dans une architecture MVC, doit être fait par le modèle ou par le contrôleur qui contrôle avant de fournir au model ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Filtrage des données, qui s'en occupe ?
Bonjour,
je me pose encore une question:
La vérification des données fournit par un formulaire html, dans une architecture MVC, doit être fait par le modèle ou par le contrôleur qui contrôle avant de fournir au model ?
Bonjour,
Je pense que c'est au controller de vérifier la sanité des données.
Le modèle ne devrait pas faire ce genre de vérification.
S'il un objet du modèle existe c'est qu'il est sain, sinon il n'a aucune raison d'exister...
C'est au modèle de vérifier le bien fondé des données et pour cause : les données attendues dépendent précisément du modèle et sont traitées par celui-ci.Envoyé par Aurelpitiless
Selon MVC, le contrôleur ne fait que transmettre les données au modèle, rien d'autre en ce sens.
Et c'est justifiable :
En poursuivant dans ton raisonnement, si le modèle est utilisé par plusieurs contrôleurs, il faudrait recopier le code vérification des saisies à chaque fois.
La réutilisation est une bonne pratique orienté objet, pas le copier-coller.
Par ailleurs, le développeur tier qui aurait le malheur d'omettre le code en question risquerait de compromettre l'application toute entière...
Bye
le contrôleur ne s'occupe que d'une chose
la logique applicative
il utilise les services du modèle
transmet les données du modèle à la vue et de la vue au modèle
Il filtre au passage les données
mais ce n'est pas lui qui sais si le contenu des données est bon.
c'est le métier qui détiens cette info
en terme de filtre le contrôleur à juste en charge l'adaptation des données à la forme attendue soit par le modèle soit par la vue.
enfin le modèle est aussi utilisable par d'autres éléments que les contrôleurs
comme les webservices par exemple
si tu mets du métier dans le contrôleur il te faudra alors le remettre dans les services
A+JYT
Je me suis mal exprimé, mais quand je parlais de sanité des données je parlais de cette étape de filtrage. (validation de type, etc).en terme de filtre le contrôleur à juste en charge l'adaptation des données à la forme attendue soit par le modèle soit par la vue.
Bien sur que le modèle ne doit accepter que des données valides...(validation d'un point de vue logique applicative).
Je vois toujours pas l'intéret (la nécessité) d'intégrer une couche de filtrage au niveau du contrôleur.
Donnez un exemple concret de ce que vous avancez.
le modèle se charge de vérifier que le numéro de code du client est conforme à la spécification d'un client
le contrôleur lui enlève des donnée issue de son formulaire les balise HTML ou le code SQL qu'un malotru chercherais à insérer
Le modèle vérifie que la date de rendez-vous demandé par le client est conforme au règles de prise de rendez-vous
le contrôleur lui récupère la chaine de caractère du champs date la dépouille de toutes les intrusion et en fait un élément du type attendu par le modèle. (init string date object etc.)
A+JYT
Ce n'est pas au contrôleur de filtrer les données en entrées, d'ailleurs le filtrage en entrée est inutile : la validation des saisies étant suffisante au niveau du modèle.
A quoi ça sert de filtrer un champ contenant des balises HTML sachant que celui-ci doit être valider par le modèle ? Ca n'a pas de sens...
...L'HTML est totalement inoffensif tant qu'il n'est pas analysé.
L'HTML devrait être échappé seulement si les données sont suceptibles d'être renvoyées au client ou si les données vont être analysées par l'application AVANT l'appel du modèle (ce cas peut se présenter si le contrôleur traite ou modifie des informations en entrée, ce qui n'est définitivement pas le rôle d'un contrôleur...(!)).
Pour les tentatives de requêtes SQL forgées, il suffit de faire des requêtes préparées.
La validation des données permet de s'assurer qu'une variable contient un certain type de données dans le format, les plages ou conditions spécifiées par le validateur.
L'échappement des données intervient après la validation de forme, à ce stade, on échappe tous les caractères dangereux.
L'échappement est également utilisé lorsque les données sont retournées au client.
Le filtrage des données fait suite à l'échappement, on formate les valeurs en vue d'un enregistrement ou d'une analyse interne (parse).
A mon avis, ce n'est pas une bonne approche que de vouloir à tout prix "corriger" les saisies utilisateur (sans parler de faire cela au niveau du contrôleur), après tout si un champ contient de l'HTML alors que vraissemblablement il ne doit pas en contenir, la seule chose à faire est de l'indiquer promptement au client et ne pas faire de son application "un redresseur de torts".
Les mauvaises saisies utilisateurs devraient être traitées comme des erreurs et non comme des exceptions.
P.S : Zend_Filter_Input.
parce que le modèle n'a pas à savoir si les données viennent d'un formulaires ou d'un webservice ou de tout autre chose
le métier lui à pour rôle de déterminer ce qui est Métier
en clair tu lui donne une date il vérifie que c'est une date valide pour sont travail et il s'en sert
il ne sait pas d'où vient cette date il ne sais si c'est une chaine de caractère qui est passer ici ou par là et qui est susceptible de contenir des parasite.
le métier est purement fonctionnel.
en clair il peut te dire que ce que tu lui donne est bien une date qu'elle correspond au règle de son métier
mais il ne peut savoir quels fitres devront être appliquer au champs du formulaire pour en faire une date vu qu'il ne connais pas le champs du formulaire.
A+JYT
Pour reprendre ce que dit Sekaijin :
Le modèle répond à une logique fonctionnelle.
Par exemple pour une prise de rendez vous, si une date est attendue, le controller doit vérifier que la donnée passée via le formulaire HTML est bien une date (par exemple du format JJ-MM-YYYY HH:MM), le modèle va lui avoir la charge de vérifier que cette date ne tombe pas un dimanche et que l'horaire soit entre 9h et 19h (par exemple).
Le modèle est chargé de faire en sorte que le domaine fonctionnelle soit respecté.
Le controller se charge de valider transformer les données pour qu'elle soit du "type" attendu par le modèle.
Il est important de séparer ces deux filtrages. Car le modèle doit être interopérable.
Admettons cette fois qu'au lieu de champs de saisie pour un rendez-vous, l'utilisateur doive fournir à l'application un fichier (type csv par exemple) qui contienne les rendez-vous.
Le modèle n'a que faire de HTML dans ce cas la. Le controlleur spécifique chargé de répondre à l'envoi du fichier, va filtrer les données du fichier pour en séparer les dates, les lieux, et les envoyer au modèle.
Donc en suivant votre raisonnement, si on me fournit un modèle je dois au préalable me renseigner profondément sur ses spécifications techniques pour ensuite créer un filtre au niveau du contrôleur, ceci dans l'espoir de formater mes données pour qu'elles soient traitables par le modèle en question...
A quel moment cela rend-il le modèle plus interpolaire ?
L'interpolarité se joue au niveau des modèles, vraissemblablement pas du contrôleur. Si d'autres développeurs utilisent vos modèles et qu'ils doivent les adapter à leur contexte, l'approche la plus commune (résolument orientée objet) consisterait à étendre le modèle en question pour qu'il accepte de nouvelles spécifications, ou mieux encore, permettre aux développeurs de créer leur propre modèle par rapport à une interface abstraite (classe abstraite ou interface).
Alternativement, si il s'agit de modification de forme, ça se passerait dans les vues.
Créer des filtres au "coup par coup" dans un contrôleur (je persiste dans l'idée que les filtres n'ont rien à faire là), ça relève du bidouillage, c'est la porte ouverte aux ennuis.
Aussi je ne comprends toujours pas cette propension à vouloir corriger les saisies utilisateur, et à la source !
Guardian_7 +1000
Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...
Pensez à consulter les FAQs et les cours et tutoriels.
FAQ Linux - Cours et tutoriels Linux - FAQ PHP - Cours et tutoriels PHP
Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.
Je n'ai rien à voir avec la société www.ovh.com !
Si je te comprends
si ton modèle est utilisé par le contrôleur c'est à lui de savoir ce qu'il y derrière donc dans la vue. pour pouvoir fileter convenablement.si en même temps ton modèle sert à une interface JSON pour de l'ajax il doit savoir ce que fait le client web pour ne pas choper des truc non prévu. et si comme moi en plus ton modèle sert au passage à des services web c'est à lui encore de filtrer les éventuels ajouts ou bricolages dans l'appel SOAP
l'indépendance du modèle est plutôt remise en question il me semble
pour moi le modèle fournis une API fonctionnelle à celui qui l'utilise de la respecter.
Mayer allait plus loin dans cette approche selon lui un appel qui ne respecte pas l'API doit générer un Arrêt brutal de l'appli (core dump) car ce n'est pas une erreur de fonctionnement c'est un programme qui est FAUT
(ça s'appelle la programmation par contrat)
A+JYT
Je ne suis pas tout a fait d'accord avec toi sekaijin.
Si mon api ne me donne pas tout ce qu'il me faut, je la surcharge pour avoir les fonctionnalité désirées. C'est pour moi un principe fondamentale de l'objet.
Par exemple, si à chaque fois que tu as affaire à du soap du dois bidouiller avant d'utiliser l'api il vaut mieux que le bidouillage soit fait une bonne fois pour toute. C'est le principe de réutilisabilité.
Quand on parle d'indépendance du modèle, je pense que l'on veut dire que le modele doit être en gros autonome et ne pas dépendre de facteur extérieur.
Adapter un modele pour qu'il puisse gère du soap, du jason ou un formulaire basic ne remet pas en cause son independance. On devrait plutôt parler de fonctionnalité de la partie metier.
Je précise que cela ne remet pas en cause le principe que du site, car ce n'est pas parce qu'on étend une api qu'il ne faut pas respecter l'api elle-même.
sympa ce post,
je donnerais plutot raison à sekaijin...
si on compare à une ampoule et à une douille ( le contrôleur étant la douille et l'objet métier l'ampoule) on peut dire que le filtrage des données est une adéquation entre l'ampoule et la douille. Il faut évidemment que le contrôleur soit adapté à l'objet.
Il est certain que si on ne veut pas faire griller l'ampoule il faut aussi protéger l'ampoule des surcharges.
ça c'est la partie validation et c'est plutôt à l'objet métier de s'en charger.
conclusion : les validators sont des membres des objets métiers déclenchés par les filtres du contolleurs ;p
Bonjour,
Confronté à la même problématique, j'ai un peu réflechi sur le sujet.
Pour moi, c'est le modèle qui doit s'occuper de valider les données qui vont être insérées dans l'application. C'est dans sa définition même.
Par exemple, on définit une classe métier 'Reservation' avec un champ 'dateReservation'.
Avant d'insérer la donnée dans l'application, on doit s'assurer que premièrement l'utilisateur a bien saisi une date valide dans le formulaire (format AAAA-MM-JJ par exemple, et qui existe, pour pas se retrouver avec un 30 février ou un 29 février sur une année non bissextile), et deuxièmement que la date saisie respecte les règles de gestion définies dans le cahier des charges de l'application (pas exemple ne pas réserver une salle de réunion un dimanche!).
Si ces deux règles sont respectées, alors la saisie de l'utilisateur est validée et on peut continuer, et si au moins l'une d'elles ne l'est pas, on lance une erreur ou une exception qui empêche l'enregistrement des données et qui sera récupérée par le contrôleur pour être affichée dans la vue et informer l'utilisateur de ce qui ne va pas dans sa saisie.
On s'arrange ensuite pour factoriser le plus possible cela dans les classes métier, par exemple en définissant une classe mère 'BusinessClass', définissant une méthode de validation de données qui utilise un attribut redéfini dans chaque classe métier et qui contient toutes les règles pour chaque champ (Pour l'instant ce n'est qu'un idée, je ne suis pas passé à la réalisation, donc il y a peut être mieux).
Cela va donc dans le sens de Guardian_7, qui parlait de réutilisation. Si je suis l'approche de sekaijin, le contrôleur doit s'assurer que le format de données est valide, et le modèle ne vérifie pas. Si mon contrôleur est buggé et passe une date au format JJ/MM/AAAA au lieu de AAAA-MM-JJ, qu'est ce qui se passe?
Ce débat pointe une limite du zend framework, qui dans ce cas n'est pas assez structurant à mon sens. Toutefois, il me semble qu'un package Zend_Form doit être introduit dans le futur...
Qu'en pensez-vous?
il ne faut pas confondre la validation des données et le filtrage des données.
le filtrage vas nettoyer les champs des éléments parasites ou dangereux pour l'application. cela ne relève pas du métier
par exemple l'interface utilisateur fourni trois champs heure minute seconde
et le modèle manipule des donnée horaires
le filtrage va consister à supprimer de ses trois champs tout ce qui n'est pas une valeur numérique. construire une heure et la donner au modèle qui lui à la charge de valider la donnée. l'heure corresponds-t-elle bien aux règles métier.
le filtrage des données est du ressort du contrôleur car lui seul sait ce que gère la vue. il fournit une donnée acceptable par le modèle qui lui la valide.
la difficulté se situe au niveau de 'il fournit une donnée acceptable' dans un champs date par exemple on peut choisir qu'une chaîne de caractère est un date acceptable et ce sera au modèle de vérifier son format et de la valider.
ou choisir que seul une Zend_Date est une donnée acceptable. au quel cas le modèle se chargera de la valider et laissera le contrôleur se débrouiller pour lui fournir une date. c'est donc ce dernier qui vérifiera le format.
le filtrage va essentiellement consister à retirer les blanc inutiles, traduire les htmlentites, rejeter les injection sql, traduire les urlencodes,
et traduire les donnée du format user au format application. (tout comme c'est le contrôleur qui avec la vue traite l'internationalisation pour la présentation.)
la validation elle à en charge la vérification de de la conformité au règles métier.
la frontière n'est jamais évidente. mais une chose est sure imaginez que vous décidiez de fournir à votre utilisateur une interface en japonais. vous ne devez intervenir que sur la vue et sur le contrôleur. les règles métier ne change pas parce-que vous affichez et saisissez vos données en japonais. de même si vous choisissez d'autre langue ou d'autre présentation.
par exemple passer de la saisie d'une dans dans une champs texte à trois selectbox, ou le contraire. ce genre de changement ne doit avoir aucun impact sur le modèle.
en gros le filtrage réponds à la question "mes données sont elle utilisables dans mon application" alors que la validation répond à la question "mes données sont-elle conforme au règle de gestion de mon métier"
1 un deux 5 trois peuvent très bien être utilisables alors que le modèle manipule des entiers. et toutes ne seront pas acceptable si la règle métier dit que le nombre doit être < 3
A+JYT
Hello,
Je ne pense pas qu'on est à faire à une limitation du framework, il y'a tous les éléments permettant de créer une logique robuste pour le filtrage, la validation et l'échappement des données. En y réflechissant bien, ce n'est pas compliqué à implémenter (eratisator, je pense d'ailleurs que tu es sur la bonne voie !)
A mon avis, si les développeurs du ZF n'ont pas implémenté un tel concept, c'est pour que les modules conservent leur autonomie. C'est une bonne chose.
En ce qui concerne l'hypothétique Zend_Form, il est préférable de savoir faire sans, parceque ce n'est pas pour demain la veille...
Donc si je pige bien, on utilise les filtres dans le contrôleur pour enlever tous les éléments indésirables pouvant avoir été ajoutés dans la saisie (du genre les html entities, les espaces à trimmer, ...), et le modèle valide les données précedement filtrées suivant les règles qu'on établit...
Dans ce cas, je ne vois par contre pas bien l'intérêt de filtrer tous les caractères non numériques d'une saisie devant être numérique (par exemple), car si on ne filtre pas la validation échouera, et si on filtre, on risque de se retrouver avec des données n'ayant pas de sens du point de vue de l'application pour les forcer à passer la validation...
Donc on filtre en entrée tout ce qui peut être dangereux pour l'application, et ensuite on valide la donnée au niveau du modèle...
Je crois que je tiens le bon bout, plus qu'à implémenter tout ça pour être le plus efficace possible!
C'est précisément l'une des raisons pour laquelle je ne suis pas d'accord avec sekaijin.
Comme je l'ai déjà dit, si les données ne sont pas du type attendu, il ne faut pas chercher à les formater, à les rendre "présentables" pour le modèle, ce n'est pas une approche logique.
Ce genre de technique peut déboucher sur un "auto-goal" en matière de sécurité.
Le module Zend_Filter_Input pour l'exemple.
Il fonctionne en trois phases (dans l'ordre) :On peut constater à travers ce mecanisme que le filtrage des données est facultatif. La plus part du temps il sera même totalement superflu...
- Il applique le(s) filtre(s) aux données.
- Il valide les données selon le(s) validateur(s).
- Il échappe les caractères spéciaux récursivement (par défaut).
La validation des données détermine si les données sont traitables par le modèle ou non. A ce niveau là, il y'a pas de danger significatif pour l'application à moins qu'il y ait une vulnérabilité au niveau de PHP (typiquement dans une fonction de la librairie interne, c'est déjà arrivé par le passé, mais c'est très rare) ou encore un contexte particulier (évaluation de code source dans un validateur par exemple).
Finalement Zend_Filter_Input échappe récursivement toutes les données. "L'échappeur" par défaut est le filtre HtmlEntities(), il convertit tous les caractères HTML non-ascii en entités.
Même si ces caractères ne sont pas échappés à ce niveau, ils ne compromettront pas l'application, ni la base de données durant leur insertion (au pire, il y aura des valeurs tronquées insérées dans une table). Cela pourra parcontre être un problème lorsque les données seront affichées ou analysées.
Les problèmes d'injections SQL ne sont pas traités au niveau du validateur, mais au niveau de l'ORM, avec des méthodes telles que quoteInto(), ou encore Zend_Db_Select, qui échappe nativement les variables dans une clause WHERE....
En conclusion, il suffit de valider les données avec les validateurs, et sécuriser les requêtes le cas échéant.
Pour te donner une idée... Tu pourrais intégrer Zend_Filter_Input dans une classe étendue de Zend_Db_Table_Abstract et redéfinir les méthodes insert() et update() de telle sorte qu'elles utilisent Zend_Filter_Input avant l'insertion ou la mise à jour de données. Si il y'a un problème de validation à ce niveau, il te suffirait de récupérer les messages d'erreurs de Zend_Filter_Input et de les placer dans une variable afin qu'ils soient retournés dans une vue.
Personnelement j'ai procédé de cette manière (bien que ce soit un peu plus poussé) et j'ai créé un View_Helper qui gère les messages d'erreurs (constantes) renvoyées par Zend_Filter_Input et les localise éventuellement dans plusieurs langues (ce qui n'est pas possible basiquement).
Bye
Dernière modification par Invité ; 19/12/2007 à 19h08.
Répondre avec citation
Partager