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.

Pour ceux qui ne le savent pas, Priston Tale 2 (PT2), The Second Enigma est un MMORPG crée par Yedang Online et distribué en Europe par Key To Play qui est très attendu par la communauté européenne de joueur. En effet, alors que Priston Tale 1 n'était disponible seulement en Corée (les chanceux) PT2 arrive pour les joueurs Européens. Au programme, un nouveau moteur graphique (basé sur l'excellent Unreal Engine) et une nouvelle stratégie de combat ainsi que bien d'autres nouveautés dont nous n'avons pas encore connaissance.

Synopsis :

L’action se situe peu après que le Dieu démon Midranda ait été vaincu et exilé par les héros de Priston Tale grâce à une armée légendaire au pouvoir assez puissant pour vaincre, ne serait-ce qu’une fois. A présent l’armée de Midranda s’est décuplée et attend sa résurrection sans trouver d’ennemi assez fort nulle part ailleurs, les espoirs et la vie du monde entier tiennent à un fil. Néanmoins, une rumeur arrive des terres lointaines, il semblerait qu’une armée nommée “enigma” pourrait vaincre Midranda et ses armées, mais il faut absolument la retrouver à temps. Le dernier espoir du monde est donc entre les mains de nos héros. Trouveront-ils la deuxième énigme à temps ?

Quelques images du jeu :

Il semble que le jeu sera disponible à la vente dès septembre mais aucune date de lancement ni de bêta-test n'a été communiquée. Ouvrez l’oeil (pixels dissimulés), le site teaser www.pt2europe.com vous révélera des contenus exclusifs du jeu...

Merci à BuzzParadise de m'avoir proposé cette campagne, juste publié déjà premier sur Google Blog.

Je ne sais pas vous, mais j'aime de plus en plus Plurk. La différence avec Twitter est réellement profonde bien qu'il manque quelques petites choses... Comme par exemple une fonction "mute all". En effet, sur chaque Plurk il est possible de désactiver les notifications sur les réponses relatives à ce Plurk.

Le problème une fois que vous avez beaucoup d'amis c'est qu'ils écrivent beaucoup et vous n'avez pas forcément envie, lors de votre connexion, de suivre les réponses aux précédents Plurk. C'est pour cela que j'ai l'honneur de vous présenter le bookmarklet ultime de tout bon Plurkien à savoir Mute All.

Mute All, une fois dans votre barre de favoris vas, en un clic, passer tout les Plurks actuellement sous vos yeux en "mute" ce qui veut dire que vous ne suivrez pas leurs réponses.

Si vous souhaitez utiliser Mute All, il vous suffit de déplacer ce lien [ Mute All ] dans votre barre de favoris.

Maintenant le côté technique, pour réaliser ce bookmarklet, je ne souhaitait pas charger JQuery (comme je l'avais fait afin de créer le bookmarklet pour ajouter une signature HTML sous Gmail) mais il me fallait la fonction getElementsByClassName mais une version qui soit compatible avec la majorité des navigateurs. Après une recherche, j'ai trouvé une fonction écrite par Robert Nyman (enfin une fonction que je n'ai pas eu besoin d'améliorer !) qui supporte l'appel multi-classe et qui permet de fonctionner sous Internet Explorer.

Voici donc un extrait du code de Mute All :

tnew = getElementsByClassName('plurk','div');
cm = tnew.length;
for(i=0;i<cm;i++)
{
    if(tnew[i])
    {
        tnew[i].onmouseover();
        tmute = getElementsByClassName('mute delete','a',tnew[i]);
        if(tmute[0] && tmute[0].className.indexOf('unmute') == '-1')
        {
            tmute[0].onclick();
        }
        tnew[i].onmouseout();
    }
}

Voici l'algorithme simplifié :

1. On récupère tout les Plurks qui ont la classe "plurk"
2. On les survoles afin d'activer/afficher le lien "mute"
3. On vérifie que ce lien est bien un lien "mute" et non un lien "unmute"
   1. Si le lien est un lien "mute" alors
      1. On clic sur ce lien.
4. On désactive le survole sur le Plurk.

Et voila !

Je suis actuellement en train de développer une application Adobe Air comme certains le savent, et j'ai besoin (ou plutôt envie) de créer moi aussi mon propre "raccourcisseur" d'url.

Apparemment la plupart des services du genre se base sur une base de données, l'objectif pour être concurrentiel est donc d'effectuer le moins de requête possible afin que le service soit le plus rapide. Après avoir soumis à la suite plusieurs urls différentes à minurl.fr, j'ai obtenu cette suite d'url :

• http://minurl.fr/12
• http://minurl.fr/13
• http://minurl.fr/14
• http://minurl.fr/15
• http://minurl.fr/16
• http://minurl.fr/17

Que peut-on en conclure ?

1. A chaque nouvelle url qui n'existe pas dans la base de données
1. On créé un identifiant, supérieur au dernier identifiant, que l'ont lie à l'url (ou plutôt un équivalent compressé de l'url).
1. Donc dans la table de notre base de données on à pour le moment les champs suivant :
1. id varchar(10) (primary) : identifiant pour l'url qui sera afficher
2. url varchar(40) (index) : champs pour l'url compressée
1. Il est préférable que le contenu de ce champs soit compressé si l'on ne veut pas une énorme base de données mais cela n'est pas obligatoire !
2. Dans cette exemple d'algorithme nous ne nous soucierons pas de la compression de l'url.
2. Si le script reçoit un identifiant
1. Chercher dans la base de données si l'id existe
1. Il existe : on retourne l'url (il faudra la décompresser si on l'a compressée)
1. On redirige vers cette url.
2. Il n'existe pas : on informe l'utilisateur.
3. Si le script ne reçoit pas d'identifiant
1. On propose le formulaire d'ajout

Maintenant, on répète l'expérience avec Tinyurl, on à donc cette suite d'url :

• http://tinyurl.com/6l74df
• http://tinyurl.com/6d8r75
• http://tinyurl.com/5o5c7d
• http://tinyurl.com/5tfegj
• http://tinyurl.com/63kjqo
• http://tinyurl.com/6ys8ym

Que peut-on en conclure ?

1. Il semble que Tinyurl utilise un système de création d'ID aléatoire, ce qui empêche toute prédiction sur le prochain ID à venir.
2. Chaque nouvelle ID créé est de la forme 5XXXXX ou 6XXXXX (d'après mes tests). Il est donc possible que les ID de la forme 4XXXXX, 3XXXXX, 2XXXXX est déjà été tous utilisé.
1. Il est donc fort probable que l'algorithme de Tinyurl, répartisse les ID fraichement créé sur deux plages qui n'ont pas encore été complètement remplie (dans notre cas 5XXXXX et 6XXXXX). Nous pouvons émettre cette hypothèse vu que les plages [4XXXXX, 3XXXXX] et [2XXXXX, 1XXXXX] on déjà été rempli.
1. Exemple, si l'on entre http://google.com l'ID de TinyUrl est http://tinyurl.com/1c2 : notre théorie est donc sans doute valide car cette adresse à été entrée dans les débuts de Tinyurl (par une personne qui souhaitait tester le service) et qu'au lancement l'algorithme devait travailler sur une plage [2XXXXX, 1XXXXX].
3. L'algorithme semble donc bien plus complexe que celui élaboré plus haut.

Nous avons donc une base d'algorithme pour créer notre service, bien sur, il est extrêmement conseillé de l'améliorer mais il reste néanmoins fonctionnel et c'est ce que l'on souhaite d'un algorithme n'est-ce pas ?