Pour ceux qui ne le savent pas, le CrossDomain est l'appellation que l'on donne à un script (qui peut être Javascript ou autre) lorsque celui-ci effectue des requêtes HTTP vers d'autres domaines différents de celui qui l'héberge.

 

Actuellement les navigateurs modernes n'autorisent pas les scripts Javascript à effectuer des requêtes sur d'autres domaines principalement pour des raisons de sécurité. Cependant, l'équipe en charge du développement du navigateur Mozilla Firefox à annoncée récemment que la prochaine version permettrait le CrossDomain ce qui est déjà le cas (dans une moindre mesure) d'Internet Explorer 8 Beta.

 

Comment les développeurs de navigateur vont-ils faire pour garder un niveau de sécurité suffisant ?

A mon humble avis, à chaque fois qu'un script voudra effectuer une requête sur un autre domaine que celui du script, l'utilisateur se verra informer de la validation ou non de la requête. Il est d'ailleurs à prévoir qu'il sera permis à l'utilisateur de mettre en place des listes "blanche" et des listes "noires" afin d'autoriser (ou non) les scripts d'un domaine à effectuer des requêtes sur un autre.

Mais cela entraînera indéniablement d'énormes failles de sécurités. En effet, dès qu'un utilisateur aura mis un domaine sur liste blanche. Prenons l'exemple du domaine free.fr. Si l'utilisateur ajoute ce domaine dans sa liste blanche au lieu de mettre le domaine xxxxxxxx.free.fr alors théoriquement tous les sites personnels hébergés chez free pourront effectuer du CrossDomain, c'est à dire le meilleur comme le pire.

Un autre exemple, il sera possible pour un site malveillant d'accéder directement à votre compte Google ou à votre boite email Gmail (pour récupérer votre liste de contact) ceci dans l'hypothèse ou vous seriez déjà connecté à ces services. Nous étudierons la faisabilité de ce cas précis dès la sortie de la version final de Firefox ainsi que d'Internet Explorer 8.

 

Les techniques actuelles pour effectuer du CrossDomain

Les développeurs web on accès à généralement 3 techniques pour effectuer du CrossDomain dans leurs applications et scripts :

• Le proxy : Votre script client (javascript) appelle un script serveur (Php, Asp, Ruby) qui va lui même effectuer la requête sur le serveur distant et qui pourra retourner le résultat de cette requête à votre script client. Cette technique est notamment utilisée par Netvibes pour récupérer les flux rss des domaines distants. L'avantage de cette technique est de pouvoir mettre en place un système de cache du côté serveur ce qui permet dans la plupart des cas une amélioration notable des performances de l'application.
• Le script (JSON) : A chaque données que l'on souhaite échanger avec le serveur on ajoute une balise "<script>" dont le script source se trouve sur un domaine distant et avec diverses paramètres. Le script serveur distant pourra alors retourner sous différents formats les informations demandées (soit en Json si il s'agit de donné ou simplement un fonction Javascript)  au script client. Il est même possible d'exécuter une fonction de callback dès que les données sont chargées.
• L'image : Contrairement aux deux techniques précédentes, l'information est unilatéral c'est à dire qu'elle va du script client vers le domaine extérieur. En script serveur est mis en place sur le domaine distant et est capable de traiter les informations passées en paramètre (par exemple : http://domaine-distant.ndd/monimage.php?valeur1=bonjour) à la fin de son exécution il retournera une image transparente ou de petite taille. Ainsi le script client, en modifiant l'adresse de cette image pourra envoyer des informations au serveur distant. Cette technique est utilisée par la majorité des systèmes de statistique (Xiti, Google Analytics, ...).
• La modification des préférences du navigateur : sous Firefox il est possible d'autoriser définitivement les requêtes HTTP (Ajax) entre plusieurs domaines via la commande javascript : user_pref("capability.policy.default.XMLHttpRequest.open","allAccess"); cependant il faudra que l'utilisateur final configure de la même manière son propre navigateur. Cette technique est donc conseillée seulement dans le cas d'un intranet d'entreprise sans connexion avec l'extérieur (internet).

 

Mot de fin

Le support ou non du CrossDomain en natif pour les navigateurs inclus des problèmes de sécurité inhérent au développement d'application web (XSS par exemple). Il faudra donc suivre de très près l'évolution des discussions sur ce sujet.

La première phase de mon stage consiste à mettre en place un script, un programme, qui permettra de synchroniser une partie de la base de données CIEL (qui contient l'ensemble des articles, famille, fournisseur, ventes, etc...) avec la base de donnée du site (Mysql).

CIEL repose sur une base de données ACCESS, le script devra donc être capable d'effectuer des requêtes sur cette base de données. La synchronisation est unidirectionnel (Ciel -> Site) lorsqu'il s'agit des articles, et bidirectionnel lorsqu'il s'agit des stocks.

Voici donc la façon dont j'effectue la synchronisation (dans cet exemple pour les articles).

Le serveur web du magasin accueil un mini-site, qui effectue via des requêtes AJAX les différents traitements de synchronisation. Le dialogue entre les deux serveurs s'effectue exclusivement en JSON, plus léger que XML et très facilement lisible en cas de debuggage.

Les requêtes AJAX envoyées depuis le serveur web du magasin peuvent être dirigées :

1. soit vers un script php interne au serveur qui va permettre de créer un interface entre les données de la base de donnée ACCESS et le reste de l'application
2. soit vers un script php "proxy" qui va effectuer une requête POST sur le serveur web e-commerce et retournera le résultat de cette requête. La requête POST ne contient qu'un seul champs : "data". Ce champs "data" - qui sera envoyé au serveur e-commerce - contient l'intégralité des variables POST ($_POST) envoyées au script proxy. Ainsi, le mini-site envoie une requête AJAX de type POST sur le script "proxy", le script proxy transforme toutes ces variables en JSON (serialisation) et les inclus dans la variable "data" qu'il envoi par POST au serveur web e-commerce, le serveur web e-commerce va alors déserialiser la variable $_POST['data'] et effectuer les traitements en fonction des paramètres transmis.

Ps : J'utilise CURL pour l'envoi de requête POST sur le serveur ainsi que PDO pour la communication avec la base de donnée ACCESS.

J'utilisais toujours le même code Ajax de mon cru pour chacun de mes sites. Seulement voila, mon code n'était pas fiable et encore moins robuste. Il arrivait qu'il charge du contenu dans la mauvaise zone en fonction de la rapidité de connexion de la personne.

J'ai donc mis en place un algorithme de "liste"/"queue" qui permet de traiter les requêtes une par une sans perte de performance à l'arrivée.

Ce code à d'abord été déployé sur Plazu Beta 5 CodeName Genesis (code js copies interdites sans accord de l'auteur !) puis sur VistaRC, et bientôt sur Amistorique, Jadup etc..

Il me reste encore une phase d'optimisation, et roulez jeunesse !

Plazu, l'application communautaire par excellence (du moins pour moi), s'exporte sur un interface client. En effet, hier dans la soirée, l'idée m'est venu de développer un interface en C# communiquant avec le serveur PHP en XML (Xml maison). 4 heures plus tard voici la première alpha :




Le but étant finalement de permettre à l'équipe de consulter sa boite mail même en étant hors ligne (ce qui n'arrive presque jamais) et d'avoir un accès rapide aux différentes fonctions du site.