halfj-site  ressources spécifications des Fûts architecture | plan du site |
6 juin 2006
3. Architecture
Résumé :
Le socle technique de la plateforme web « Les Fûts » suit plusieurs lignes directrices.
Couches
La plateforme web « Les Fûts » a une architecture organisée en couches :- Couche Présentation. C'est ce qui est renvoyé à l'utilisateur, ce qu'il voit à travers son navigateur. De l'UTF-8, du HTML 4.01 conforme, de la CSS standard, deux lichettes de JavaScript, emballé c'est pesé.
- Couche Applicative. On y gère la session du site courant, l'authentification éventuelle de l'utilisateur, ses préférences. On traite en local les actions de consultation et de recherche, et on pose des demandes pour les actions de créations, modifications et suppressions.
- Couche Communication Applicatif/Métier. Les serveurs applicatifs émettent des demandes vers le serveur métier. Le serveur métier distribue des données vers les serveurs applicatifs. Il y a une couche dédiée à cette communication. En particulier, lorsqu'une demande applicative met du temps à recevoir sa réponse, on peut tomber en timeout applicatif, c'est-à-dire que l'utilisateur a un affichage clair : « votre demande a été prise en compte, mais elle n'a pas encore été traitée. Merci de revenir sur cette page d'ici une minute ».
- Couche Métier. On y reçoit des demandes d'actions, on les traite, en résolvant au besoin les conflits, et on distribue les résultats vers les serveurs applicatifs concernés.
- Couche Données - Cache Applicatif. La couche applicative a besoin de données en local pour la consultation. Ces données sont des extraits des données métier, et sont distribuées par le serveur métier.
- Couche Données - Objets Métier. Les données de la couche métier sont centralisées. Les objets métier sont versionnés.
- API publique de connexion aux Fûts. Le serveur métier peut être invoqué directement depuis l'extérieur, grâce à une API publique de services web REST.
Pour chaque site associatif, le serveur applicatif utilise PHP 4, Sablotron, MySQL 5, chez Free ou équivalent. Il est autonome pour les fonctionnalités de suivis de sessions, de consultation, et de recherche mono-site. Ses données sont préalablement calculées puis distribuées sous forme de cache par le serveur métier. Ce choix garantit des bons temps de réponse et une répartition de charges.
Le serveur métier est partagé par les associations. Il utilise J2EE 1.3, ServiceMix 2.0 et MySQL 5. Il est invoqué à chaque publication, que ce soit une publication d'article complexe ou de simple commentaire. Sa charge est estimée à 10% de l'utilisation globale du système.
La communication entre les deux serveurs se fait à base de protocole REST.
Les couches sont servies de la façon suivante :
- La couche de présentation est servie par le serveur applicatif.
- La partie « Consultation » de la couche applicative est servie par le même système que la couche de présentation : PHP 4, Sablotron, MySQL 5, chez Free ou équivalent. Ces données de la couche applicative sont calculées et distribuées sous forme de cache par le Back Office.
- La partie « Action » de la couche applicative fait l'objet d'une communication asynchrone entre le serveur applicatif et le serveur métier.
- La couche métier est implémentée en services web.
Sessions
Les sessions applicatives sont gérées en local, par chaque serveur applicatif.Le timeout par défaut est de 30 minutes d'inactivité.
La gestion du SSO se fait par l'intermédiaire du serveur métier. On considère que la fonctionnalité de SSO est une fonctionnalité métier, car il peut y avoir des problématiques de gestion de conflits, notamment au niveau des habilitations.
Le suivi de sessions doit pouvoir se faire entièrement par URL-rewriting.
L'utilisation de cookies, quand c'est possible, est là à des fins de contrôles, mais pas suivi de sessions. En particulier, lorsqu'une session disparaît de l'URL mais qu'un cookie est présent, on contrôlé qu'il s'agit d'une session qui existe réellement, on émet un log de warning, et on recrée la session dans les URLs. Les heuristiques sont à étudier.
On ne peut pas s'appuyer uniquement sur les cookies, à cause de la fonctionnalité voulue de SSO entre différents serveurs applicatifs, qui sont de simples serveurs Apache/PHP.
Il y a une question de rapprochement des sessions : comme les résolutions de conflits inter-sites se font de façon asynchrone car on passe par le serveur centralisé, un utilisateur pourrait très bien se logger sur deux sites différents, que chaque site lui crée une session, et qu'on s'aperçoive plus tard (le serveur centralisé doit interroger les serveurs applicatifs à intervalles réguliers) qu'il s'agit du même utilisateur, donc qu'on doit fusionner ses deux sessions.
Si une session passée dans l'URL est invalide, l'action demandée est quand même analysée, et si elle est possible (par exemple une consultation publique) on recrée une session, et on lance l'action. Les heuristiques sont à étudier.
Tout utilisateur, enregistré ou simple invité, doit avoir la possibilité de clôre lui-même sa session. Cette action supprime côté serveur applicatif tout ce qui était lié à la session : résultats de recherche, formulaires en cours, etc.
Sécurité
D'un point de vue technique, il n'y a strictement aucune sécurité dans les Fûts v1.0.En effet, Free ne propose pas le SSL.
En fait, le système d'authentification par un identifiant et un mot de passe, système qui est prévu dès le lancement, ne sert pas à la sécurité (il ne saurait arrêter aucun pirate), mais à l'identification des utilisateurs, et notamment à savoir si tel utilisateur est un administrateur ou non.
Récapitulatif de la sécurité des flux :
- les requêtes HTTP qui arrivent sur le serveur sont systématiquement analysées, contrôlées, et transformées en objets. On ne déclenche jamais aucune action à partir des requêtes HTTP elles-mêmes. Exemple de ce qu'il ne faut pas faire : construire des requêtes SQL vers la base de données en utilisant les paramètres HTTP sans les encoder.
- la saisie éventuelle d'un identifiant et d'un mot de passe, produisent un flux HTTP en clair vers le serveur applicatif.
- les communications des serveurs applicatifs vers le serveur métier (envoi de demandes) se font par des flux HTTP en clair.
- les communications du serveur métier vers les serveurs applicatifs (distribution de données) se font par des flux HTTP en clair.
- les données soumises à habilitations ne sont pas accessibles par une bête URL. Exemple de ce qu'il ne faut pas faire : lire sur le système de fichiers un fichier dont le nom est dans l'URL.
- les serveurs applicatifs stockent leurs données en clair sur le système de fichiers et dans une base MySQL.
- le serveur métier stocke ses données en clair sur le système de fichiers et dans une base MySQL.
- les utilisateurs peuvent arriver en tant qu'invités, et ils ont alors accès à toutes les parties publiques des sites associatifs. La session est créée dès que le besoin existe. Ces utilisateurs peuvent modifier des préférences minimales, mais celles-ci seront effacées à la fin de la session.
- les utilisateurs enregistrés peuvent s'identifier. Ils peuvent modifier leurs préférences, et celles-ci seront stockées de manière persistante.
- selon leurs habilitations, les utilisateurs accèdent à plus ou moins de fonctionnalités.
Respect des standards
Le standard choisi pour le HTML envoyé aux utilisateurs est le « HTML 4.01 Transitional ». En effet, les vieux navigateurs ne comprennent pas le XHTML.Pour la même raison, CSS 1.0 devrait être suffisant.
Modules internes, modules externes
Les Fûts proposent des fonctionnalités de blogs, de forum, de wiki, le tout mâtiné de SSO.Dans un premier temps, on propose que les modules suivants soient implémentés de façon monolithique :
- blog,
- forum,
- wiki.
- serveur d'identités (voir les approches Account Authentication de Google, InfoCard de Microsoft, Project Higgins de IBM et Novell, et surtout OpenID de VeriSign)
- stockage de documents,
- stockage d'images (voir l'approche Flickr).
Pour le serveur d'identités, j'ai peur qu'il ne faille développer quelque chose soi-même pour commencer, mais ce sera de toute façon minimal. L'important est de penser découplage dès le début.
| Copyright 2006, David Andrianavalontsalama |
