Format d'impression
PHPLIB : Un modele sécurisé pour la circulation des données en PHP
Auteur/Traducteur : tobozo@softhome.net
Date de création : 19 mars 2001
Dernière modification : 29 novembre 2002
Vu 12278 fois

References :
http://www.kneschke.de/projekte/ldap/php/future/ (inspiré du compte rendu de la conference a cologne)
http://phplib.sf.net
http://www.phpslash.org

  [intro]
  Il etait une fois un langage bien sympa qui acceptait sans broncher plein d'erreurs
  de syntaxe avec des styles differents de codage.
  Dans le but de developper simplement des applications, ses auteurs avaient réussi
  a séparer les donnés de la couche de présentation. Ce langage s'appellait php-fi et
  a bien évulué depuis ce jour.
  Malheureusement l'utilisation etait devenue trop simple et la saison des bulletins de
  sécurité approchait avec ses pluies d'annonces. Ce phenomene cybermeteo etait surtout
  dévastateur pour les produits qui utilisaient "l'image de marque", et ceux qui le
  consommaient malgré eux ne pouvaient qu'en constater l'effet nefaste sur leur startup.
  [/intro]
 
  PHPLIB est peut etre devenu obsolete depuis que php4 est fourni avec PEAR, mais l'influence
  de ses methodes est loin d'etre terminée. L'abstraction a tous les niveaux de la
  circulation des données force les developpeurs auto didactes a adopter des methodes de
  programmation plus propres tout en permettant une adaptativité qui s'avere etre bien
  moins limitée que le codage sauvage.
 
  PHPLIB est aussi synonyme de portabilité, de sécurité (bien qu'elle ne soit pas prise en
  charge), et de stabilité (tout au moins au niveau du code).
 
 
  Cadre d'application
  -------------------
 
  Les problemes soulevés par le manque d'empathie de la part des nouveaux acteurs de cette
  scene ont rapidement mis a jour des points critiques qui aident a comprendre pourquoi une
  bonne approches de PHPlib (tout au moins l'acquisition de connaissance semblables) est
  nécessaire pour maintenir une application web dans un environnement sécurisé sans rester
  dependant de ses concepteurs.
 
 
  Afin de permettre un developpement simple de l'application, il faut se livrer a un petit
  exercice qui consiste a utiliser un modele de donnees simple, et une représentation
  segmentee en differents modules.
 
  Application ^
  |
  Templates | Présentation
  |
  Formulaires |
  +---------------
  Relations |
  |
  Table Proxy | Données
  |
  Source de données v
 
 
 
  Interaction entre les modules individuels.
  ------------------------------------------
 
  Source de donnees
  L'accès aux données est originalement définie sur une interface choisie arbitrairement
  selon les ressources locales (ex:DB_Sql). Le serveur web peut aussi etre la source de
  donnees, puisqu'il nourrit formulaires (Get, Post, Cookie)
 
  Table Proxy
  La TABLE_PROXY permet d'abstraire les donnees de la requete sur la source et joue
  egalement le role de containeur pour ces memes donnees.
  Son role est similaire a celui du xml pour le html par la structure qu'elle fournit
  aux données qu'elle contient.
 
  Relations
  On construit les relations entre les différentes données sur le module de relations.
  L'utilisation de metadonnées est rendue possible a ce niveau la (ex : Foreign Key).
  A partir de cette couche on peut dire que toutes les données ont été COMPLETEMENT
  abstraites, de facon a produire au moment approprié une interface simple, agréable,
  fonctionnelle et répondante.
 
  Formulaires / Templates / Application
  Les formulaires (OOH/IXT voir les deux modules PHPLIB) operent l'abstraction des
  champs (input) de l'interface. Ce qui en ressort est également exporté en direction
  des templates, puis vers le html. Il est aussi possible d'utiliser XSLT a ces niveaux.
 
 
  Chaque niveau reste indépendant de l'autre et peut etre utilisé séparément du moment
  que les interfaces auxquelles il s'attache sont définies en conséquence.
 
 
 
  Circulation des données
  -----------------------
 
  La modélisation des données est produite au moyen du module de relation et se base sur
  la table_proxy (qui représente le conteneur de données).
 
  Ces données peuvent etre présentées par l'interface, puis de l'interface renvoyées vers
  leur origine.
 
  Le retour des données prend place a l'interieur du module de relation qui garantit la
  cohérence entre les différents champs utilisés.
 
  Le réexamen des différentes zones de données règle le Proxy, puisque chaque champ est
  évalué par les fonctions correspondantes (check_row..).
 
  Le Proxy par définition ne connaît pas le lien entre les données, cette tâche appartenant
  au module de relation, toutefois il garantit sa validité par le format des données
  qu'il traite. Le processus comp;et de traitement prend donc place ici.
 
  La présentation des donnees etant prise en charge dans le module formulaire et le
  module template, on peut donc etendre le diagramme de depart comme suit:
 
 
  Application ^ Circulation des données
  |
  Templates | SORTIE
  |
  Formulaires |
  | -------------
  Relations | TRAITEMENT
  | -------------
  Table Proxy |
  | ENTREE
  Source de données |
 
 
 
 
 
  Problemes et solutions :
  ------------------------
 
  Il faut noter qu'aucune des couches n'anticipe sur la couche suivante, partant du
  principe que le bloc suivant s'en occupera (notion d'heritage).
  Cette situation peut etre genante lors de l'integration d'applications deja complexes,
  mais elle a le mérite de forcer la route du developpement vers des methodes de codage
  plus sécurisées et plus stables.
 
  Il existe certaines dépendances entre les modules, en ce qui concerne les données :
  la Table_Proxy doit vérifier les champs avant de les passer
  les formulaires peuvent avoir a fournir du JS
  les relations entre champs doivent etre clarifiées au niveau des dependances
  Cette variante impose une modélisation externe des données, de sorte que les contrôles
  correspondants puissent devenir automatiques.
  L'utilisation des templates d'un coté et de l'abstraction des formulaires de l'autre
  peut pousser a confondre ces deux couches au point d'en abandonner une au profit de
  l'autre sous pretexte de redondance.
  Cela ne fait que souligner le besoin réel d'un nouveau format intermediaire entre
  la couche relation et la couche application : on devrait recourir au xml comme méthode
  préférée, de sorte que de toutes les couches superieures bénéficient d'un accès simple
  au couches internes et ainsi abstraire completement le contenu logique.
 
 
(copyleft) 2001 tobozo@softhome.net 19-mar-2001 16:33:02 GMT &Ext