avantages inconvenients de la sérialisation dans un site web ???

[Démosthene]

Bonjour à tous,

Je ne suis pas certain d'être sur le bon forum, mais plutôt en marge.
Je rencontre un doute de conception dans un site web en php.

J'ai une application php que je veux indépendante de la couche données
(sql, fichiers texte ...). je me demande les avantages et les
inconvénients qu'apporteraient la sérialisation de mes classes en vue de
passer le "contexte-objet" de page en page avec une actualisation de
loin en loin.

* Je vois déjà quelques soucis de synchronisation (requete /
actualisation), que je peux régler avec des verrous.

* J'alourdi mon serveur et allège ma couche de donnée

* Je ne sais pas par contre si la sécurité des données est gravement
mise en danger ou pas, j'ai des soupçons que oui.

Avez-vous déjà retenu cette manière de faire dans un environnement
apache/php/??? ?


Je lirais avec attention toutes vos remarques

Cordialement Démosthène

[zwetan]

Bnojour,

Post by Démosthene
Je ne suis pas certain d'être sur le bon forum, mais plutôt en marge.
Je rencontre un doute de conception dans un site web en php.
J'ai une application php que je veux indépendante de la couche données
(sql, fichiers texte ...). je me demande les avantages et les
inconvénients qu'apporteraient la sérialisation de mes classes en vue de
passer le "contexte-objet" de page en page avec une actualisation de
loin en loin.

[snip pour reprendre les points plus loin]

Post by Démosthene
Avez-vous déjà retenu cette manière de faire dans un environnement
apache/php/??? ?

non, mais c'est ce que je fais dans un environment IIS/ASP/ASP.NET avec
JScript/JScript.NET
donc je peux en parler un peu :).

rester dans un context-objet ca a pas mal d'avantages mais attention a ne
pas penser
que au serveur, pense aussi a ton client.

si tu restes dans une logique de navigation page à page:

page1 -> urlencoding -> page2 -> urlencoding -> page3
ou
page1 -> serialisation-objet -> page2 -> serialisation-objet -> page3

le seul avantage de la serialisation est de ne pas faire le parsing de
l'ulencoding ala main

par contre si tu peux garder une page et juste echanger les donnees entre le
client et le server
là la serialisation objet montre tous ses avantages:

1 seule page
client supportant AJAX <- serialisation-objet -> serveur avec PHP

ca permet de commmuniquer en "objet" entre le client et le serveur,
d'avoir un protocole commun et en gros de reduire le transfert de données
(car on ne transfere plus les pages, mais que leurs données).

Post by Démosthene
* Je vois déjà quelques soucis de synchronisation (requete /
actualisation), que je peux régler avec des verrous.

si tu restes dans une logique de navigation page à page
tu verras que la serialisation peut transmettre plus de details et garder le
typage des données
mais que par contre ca ne va pas forcément alleger ton transfert de données
page à page.

je laisse le 2nd point pour le traiter a la fin, pour me concentrer sur la
securité,
le plus gros probleme.

Post by Démosthene
* Je ne sais pas par contre si la sécurité des données est gravement
mise en danger ou pas, j'ai des soupçons que oui.

Si tu utilises la serialisation tel quelle de PHP il y a des risques oui:
- injection de données
- données malformées pouvant planter le serveur
( - execution de code sur le serveur )

l'ideal et de passer par son propre parseur, mais bon c'est compliqué
et ca prends plus de ressources.

exemple de situation critique:
- tu geres les donnees d'une bibliotheque, tu as une classe "Livre"
decrivant le titre, l'auteur etc.

- a un moment tu as des pages /saveToLibrary.php /deleteFromLibrary.php
si tu ne verifie pas le contexte de sécurité pour ce genre de pages
tu laisses n'importe quelle personne connaissant la serialisation PHP
injecter ou supprimer n'importe quel données de la bibliotheque.

- si tu ne fonctionne pas dans le mode pages à pages
en ayant 1 seule page a laquelle tu envoies des commandes
par ex: /gateway.php
là tu devras en plus filtrer les commandes authorisées
en fonction du contexte de securité (en plus de valider les données
associées ala commande)

etc. etc.

Prends toi un bon bouquin qui parle de la securisation des applications web.

voir aussi: http://www.hardened-php.net
par ex: http://www.hardened-php.net/advisories/012004.txt

Post by Démosthene
* J'alourdi mon serveur et allège ma couche de donnée

Pour alourdir le serveur ca depends:
- transferer juste des données plutot que des pages ca allege la bande
passante
- verifier ces données, et/ou faire son propre parsing de ces données ca
alourdi les cycles proc

Pour la couche de données elle-meme, c'est a peu pres pareil:
- si tu gardes les données en mémoire, tu alleges les acces I/O ou vers la
BDD ou autre
- si tu serialises certaines données sur le disque ou une BDD ou autre
ca te permet de garder des "globals" accessible de partout sans allourdir
la mémoire

il y a bcp de paramettres qui rentrent en jeux...

si tu veux approfondir l'idée, regarde ce qu'il se fait déjà:
SOAP, WDDX, O/R mapping (npersist, hibernate), etc.

voir ici aussi:
http://jpspan.sourceforge.net/wiki/doku.php?id=php:serialization
qui resume bien la situation

zwetan

[Démosthene]

Merci de cette réponse dense et très intéressante ;)

Post by zwetan
par contre si tu peux garder une page et juste echanger les donnees entre le
client et le server

Je veux éviter des requètes SQL à n'en plus finir, et donner la
possibilité de choisir le support de donnée entre SQL et XML.

Post by zwetan
1 seule page
client supportant AJAX <- serialisation-objet -> serveur avec PHP

Vous me confirmez ce que je présentais, j'ai fait des essais sous IE et
Firefox d'envoi de requète en restant sur une même page. Il me reste à
évaluer le surcroit de travail pour maitriser Xul.

Post by zwetan

Post by Démosthene
* Je ne sais pas par contre si la sécurité des données est gravement
mise en danger ou pas, j'ai des soupçons que oui.

Je me suis mal exprimé : je protège depuis un bon moment chaque variable
qui entre sur mes pages. Je me demandais simplement si par la
sérialisation, d'autre portes étaient à protéger.

Post by zwetan
- injection de données
- données malformées pouvant planter le serveur
( - execution de code sur le serveur )

Celà m'est arrivé (injection SQL), c'est l'apocalypse quand celà arrive
;) depuis, je filtre jusqu'au nom des prefixes des tables.

Post by zwetan
SOAP, WDDX, O/R mapping (npersist, hibernate), etc.

Je vais de ce pas lire la doc Php sur WDDX - je n'en connais que le nom -

Merci ;)