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 0 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