Archive for the 'Ajax' Category

Ajaxian::PHPClasses.org Chooses iFrames over Ajax?

Friday, April 7th, 2006

Source: http://ajaxian.com/archives/phpclassesorg-chooses-iframes-over-ajax

PHPClasses.org choisit les iFrames au détriment d’Ajax?!

Quand les gens regardent pour la première fois les possibilités d’Ajax, il semble qu’ils soient immédiatement retournés et s’y lancent à pied joint. Bien sûr, d’autres plus mitigés, prennent Ajax comme un moyen d’ajouter certaines fonctionnalités à leur site web, mais ne semblent pas convaincu. Ils se retranchent donc vers des notions connus et qui marchent pour eux - la traditionnelle iFrame.

Une exmple est ce post sur le blog de PHPClasses qui parle du choix de Manuel Lemo de passer par des iFrame au lieu du XmlHttprequest pour la nouvelle version de son site, PHPClasses.org.


Ce plu-in Ajax que j’ai développé n’utilise par l’objet XMLJttpRequest. Il utilise à la place des iFrame cachées. Certains considèrent l’AJAX comme la seule méthode pour une interaction serveur-navigateur, grâce à l’objet XmlHttpRequest. Cette définition est fausse puisqu’on peut utiliser les iFrame pour les même besoins.
Je voudrais donc partager avec vous les raisons pour lesquelles j’ai choisi les iFrames plutôt que l’objet XMLHttpRequest.

Cretaines de ces raisons sont: “Compatibilité navigateurs”, “Les contraintes de sécurité des navigateurs” et “Rapidité de réponse”. Il base sa discussion sur une présentation qu’il a assisté qui disait que Ajax convenait pour de petites requêtes, mais qu’une iFrame pouvait supporter des requêtes plus larges, d’une façon plus facile et plus rapide que son homologue. Il cite aussi une autre raison pour sa décision: avec une connexion Ajax, les données ne sont disponibles qu’à la fin de la requête, alors que l’iFrames peut renvoyer des données partielles. Quelques autres arguments sont avencés, comme la possibilité de faire plusieurs actions dans la même requête et qu’il n’y a pas de méthode directe qui gère l’upload de fichier.

Babozor:
Je ne suis pas sûr que ce choix soit impartial, mais peut être pour aller à contre-courant de la tendance actuelle. Personnellement je ne vois pas l’intérêt d’un iFrame caché, alors que même pour des applications aux besoins gourmands, l’Ajax peut soutenir largement la comparaison. Il n’en reste pas moins, que la question reste ouverte…

Ajaxian::Script.aculo.us 1.6 Released

Friday, April 7th, 2006

Source: http://ajaxian.com/archives/scriptaculous-16-released
Script.aculo.us 1.6 disponible

Script.aculo.us version 1.6 est disponibe (et qui suit la mise en ligne de la version 1.1 de Rails), comme l’avait dit Thomas Fuchs.


Script.aculo.us 1.6 marque une divergence avec Prototype 1.5 (la version 1.4 n’est plus supportée), avec de merveilleuses nouvelles fonctionnalités et est passé par un recodage complet pour tirer le meilleur parti de Propotype 1.5.
Les nouvelles fonctionnalités incluront la possibilité de scroller des fenêtres pendant le drag & drop, des optimisations de performance et des corrections de bug.
Pour voir des combinaisons vraiment cool des nouvelles fonctionnalités de Prototype avec la dernière version béta 1.6 de script.aculo.us, regardez les exemples 1 et exemples 2 (accesibles aussi depuis le functional test suite).

Juste quand on commence à piger le truc, ils rajoutent d’autres trucs cool :)

Babozor:
Après un test léger, ces nouvelles fonctionnalités m’ont l’air plutôt gadget qu’autre chose, mais il faudrait se plonger dans le code de la nouvelle version pour voir l’étendue de la réorganisation du code pour permettre une meilleur implémentation du code avec Prototype 1.5…
A voir…

Ajaxian::An Ajax Powered Tool

Friday, April 7th, 2006

source: http://ajaxian.com/archives/an-ajax-powered-color-tool

Un outil pour vos couleur en Ajax

Malheureusement, tous les développeurs web n’ont pas le dont inné du sens du design et des couleurs. Ils codent des pages qui fonctionnent, et se préoccuperont après de tous les “bidules” autour, une fois que le travail de ccodage sera terminé. Heuresuement pour eux, certaines ressources sont là pour les aider, comme cet outil bien pratique de Sharewonders.com.

Quand vous chargez la page, vous verrez une barre sur votre gauche avec un lien “Show” en haut. Cliquez dessus et vous serez accueilli par une interface sobre pour vous aider à choisir des couleurs coordonnées qui vont avec votre sélection de couleur. en cliquant sur une des couleurs dans un des blocks du haut, vous verrez comment les différentes zones réagissent avec les couleurs coordonnées. Les blocks de couleurs plus gros (au milieu de l’interface) peuvent ensuite être glissé sur la partie droite de la page pour créer une colorisation pour votre site.

Ouais, c’est un autre sélecteur de couleur de plus, pas vrai? Et bien, c’est un peu plus que ça. Quand vous avez sélectionné la couleur dans les boites à votre droite, vous pouvez les sauvegarder avec un nom de thème et une description et ils seront ajouté aux “10 thèmes les plus récents”. Ils utilisent une connexion Ajax pour faire des aller-retours avec le serveur pour que la sauvegarde soit transparente. Cliquez sur le lien “view” à côté d’un thème et la page se rechargera avec les couleurs du thème sélectionné.

Le site est toujours en développement, donc je sais que d’autres fonctionnalités suiveront. Les autres fonctionnalités que j’aimerais voir sont plus de layouts et d’options pour les couleurs. J’aime que l’on puisse “affiner” des thèmes pré-enregistrés, en faisant de petits changements de couleur jusqu’à obtenir entière satisfaction.

Babozor:
Le service est clairement encore en béta, mais il laisse augurer avec quelques menus aménagement un outil pratique pour prévisualiser rapidement des thèmes de couleur différent pour votre site, pratique… et tout en Ajax, off course…

Ajaxian

Friday, April 7th, 2006

Je vais tenter dans les jours/semaines/mois qui viennent de traduire et publier certaines news publiées sur le site Ajaxian, référence dans tout ce qui touche de près ou de loin à l’Ajax (Asynchronous JavaSCript and XML)…
Ces posts seront anotés comme suivent:

Ajaxian::Titre du post

En espérant que ces petites traductions aideront certains programmeurs français qui comprennent mal ou peu ou pas du tout l’anglais (et c’est vraiment bien domage pour eux) et pour les inciter à se pencher de plus près sur l’Ajax (en attendant qu’un vrai site français prenne le relais).

AJAX & Sécurité

Thursday, April 6th, 2006

Source: Ajaxian (http://ajaxian.com/archives/is-your-application-secure-enough)
J’ai essayé sans succès de traduire un article qui me semblait intéressant en première lecture (et linké ur l’excellent site Ajaxian), sur AJAX et les possibles failles de sécurité entourant l’objet XmlHTTPRequest.
L’article débute plutôt bien en nous faisant miroiter des failles monstrueuses de sécurité dans cette technologie chouchoute des derniers services web à la mode.
Que néni je dois le dire après lecture et tentative de traduction de l’article. Il est vrai que l’article met en avant le danger des requête GET par rapport aux requêtes POST (mais bon ça c’est un peu du réchauffé) et de la nécessité de l’authentification pour des actions “desctructives”.
Néanmoins, cet article reste intéressant dans son approche, puisque l’utilisation d’AJAX et donc de ses risques potentiels, risque de pousser les développeurs à mieux sécuriser leurs code…

Sur certains points, les gars d’Ajaxian ont l’air plutôt d’accord avec moi, je cite (et je traduis plus ou moins fidèlement):
“La sécurité et Ajax est dans tous les esprits ces derniers jours, que ce soit pour une petite application en interne, ou une énorme application servie a un publique massif. Se préocuper de la sécurité de votre projet n’est jamais une mauvaise chose, et pour vous aider à vous diriger dans la bonne direction, je voulais partager avec vous ce post sur Darknet.org.uk qui pose la question suivante: “Votre application est-elle sufisament sécurisée?”
…citation de l’article en question…
Le post en question mentionne certains des problèmes qui peuvent être présent, la plupart du temps par une mauvaise compréhension du côté serveur des applications. Il fait aussi mention d’une solution possible pour améliorer la sécurité de votre application: une genre de “séquence numérique” utilisable comme clef dans la chaine de caractère de la requête (aussi hazardeuse que possible) envoyée avec la requête pour validation par le serveur. Il fait aussi une brève mention des infections en JavaScript et de certains problèmes liés à ceux-ci.”
Voici donc ma tentative de traduction de l’article en question:
(J’ai abandonné la traduction quand l’auteur zappe d’un sujet à un autre sans autre forme de procès et commence à s’embrouiller… ce qui me semblait intéressant est très vite devenu confus et litéralement intraduisible)
http://www.darknet.org.uk/2006/04/ajax-is-your-application-secure-enough/
Navaho Gunleg le 5 avril 2006 à 9h55

AJAX: Votre application est elle sufisament sécurisée?

Introduction
On le voit de plus en plus ces jours ci. Les applications web deviennent plus astucieuses de jour en jour, utilisant divers nouveautés techniques, introduites récemment dans des navigateurs tels que IE et Firefox. Une de ces nouvelles techniques utilise le JavaScript. Plus précisément, la classe ou objet XmlHttpRequest.
Les applications de type WebMail les utilisent pour mettre à jour rapidement la liste des messages dans votre boîte de réception, pendant que d’autres applications l’utilisent pour suggérer divers mots clefs en temps réel. Tout cela bien sûr sans recharger la page principale.
Avant d’explorer les éventuelles faiblesses et choses à garder à l’esprit quand on implémente une application Ajax, nous allons nous intéresser à comment marche cette technologie.

Les bases
Asynchronous JavaSCript and XML aka AJAX fait a peu de chose prêt ce qui suit. Mais laissez moi vous illustrer ceci avec un exemple. Vous êtes dans votre boîte de réception et vous voulez supprimer un message. Normalement, avec une application HTML standard, les requêtes POST et GET seraient traitées, et vous redirigeraient vers votre Boîte de réception, en rechargeant la page.
Avec l’objet WmlHttpRequest, cette requête peut être faite sans recharger la page.
En tâche de fond, un appel est fait, qui effectue l’action sur le serveur, et éventuellement répond avec des données. (A noter que cette requête ne peut être possible que pour un script hébergé sur le même serveur. Cela laisserait une possibilité d’intrusion massive si je pouvais créer un page HTML, qui en utilisant du JavaScript, pouvait faire quelques milliers de requêtes sur un autre site web…)

La question
Quelques applications web, telles que les application mails, peuvent avoir des fonctionnalités desctuctrices qui peuvent être détournées. La question est donc, la majorité des applications web utilisant AJAX pourront ils faire la différence entre une vraie et une fausse requête XmlHttpRequest?
Savez vous, si vous avez développé une application AJAX récemment, si votre application peut faire cette différence - et le fait elle correctement?
Vérifiez vous le referer ou d’autres informations triviales comme le user-agent? Il y a des chances pour que vous ne sachiez même pas de quoi on parle. Il y a aussi des chances pour que d’autres personnes le sachent.
Pour être sûr que le système que vous avez implémenté -ou que vous comptez implémenter- est sufisament sécurisé, et donc digne de confiance, vous vous devez de regarder un peu autour de votre script.
Par exemple, la première fois que j’ai découvert cela était en travaillant sur une fonction pour un site de ringtones. De façon basique, l’URI de la requête XmlHttpRequest ‘len’ était un paramètre qui spécifiait la longueur du fichier de preview, qui semblait utiliser le fichier d’origine. En entrant l’URI dans un navigateur, et en spécifiant une grande valeur, quelqu’un pouvait trsè bien récupérer tout le fichier.
C’est souvent une erreur fatale: implémenter une interface AJAX qui accepte les requêtes en GET. les requêtes en GET sont les plus simple à berner.

Ma prédiciton
Les applications les plus populaires que j’ai vérifié sont conçu de telle façon qu’ils utilisent un séquence aléatoire de nombre: le serveur envoi un ordre, l’encode, et dit à l’application quel est la séquence numérique suivante pour telle ou telle commande. C’est assez obscur en JavaScript et super chiant à disséquer, mais pas impossible.
Et comme vous avez déjà pu le noter, si l’authentification sur l’objet XmlHttpRequest est défectueuse, elle laisse une oportunité pour une utilisation malicieuse. C’est exactement ici que nous pouvons nous attendre à certaines faiblesses et trous qui ne tarderont pas à être exploités. Il doit y avoir une authentification correcte, partour, tout le temps.
Tous ces systèmes sont créés par des humains, il y a des chances pour que ce ne soit pas fait proprement ou de la bonne manière.
Analyse du traffic HTTP
Analyser le traffic HTTP avec des outils tel que etheral, peut s’avérer utile pour savoir si votre application est sûr du point de vue de l’exploitation. Cette application permet de facilement filtrer et suivre les flux TCP pour que vous puissiez analyser ce qui se passe exactement.
Si vous voulez enquêter sur votre propre application, l’utilisation d’un sniffer n’est pas nécessaire, mais je vous suggérerais de laisser cette tâche à un collègue qui n’a pas implémenté le service, qu’il joue un peu avec et qu’il essaye de s’y introduire.
Cookies
Les cookies sont nos amis quand il sagit de rechercher les vulnérabilités des applications AJAX.
Si l’interface XmlHttp est protégée par des cookies, l’exploiter est l’enfance de l’art, quand votre navigateur envoi une requête au serveur, il envoi aussi un cookie avec cette requête.

Ajax… génialissime, mais quelques problèmes

Monday, April 3rd, 2006

Depuis quelques temps je m’intéresse à tout ce qui touche de prêt ou de loin à ce que tout le monde apelle le Web 2.0
La définition de ce Web 2.0 reste encore floue, mais en gros le but est de faire des services plus pratiques, qui prennent en compte les réels besoins des utilisateurs, etc…
Une des technologies fondatrices du Web 2.0 est Ajax (Asynchronous JavaScript And XML), cela permet entre autre de bouger certains layers, de recharger juste du contenu dans des bouts de page, etc… cette technologie est vraiment démentiel, elle permet une interactivité hors du commun, de bouger les éléments de la page, de recharger juste les informations qu’on a besoin, etc…
Juste pour le fun, j’ai refait le site de ma fille tout en Ajax.
Le site de ma fille est assez basique, il nous permet de poster des photos, avec un petit commentaires et permet aux vsisteurs de poster des articles, regarder les photos, etc…
L’ancienne version du site était basique, vous cliquez sur le calendrier, les images de la date s’affichent, et ensuitge en cliquant sur les différents thumbnails, vous ouvrez un popup avec l’image concernée.
Le nouveau site reprend quasiment les même fonctionnalités, mais sans aucun rechargement de page, on ne recharge que le layer concerné et franchement c’est bien pratique. De même plus de popup, l’image apparaît à l’intérieur de la page, c’est plutôt joli.
Mais pendant ce ‘petit’ test, j’ai pu me confronter à un désaventage de cette technique.
J’écris en français, donc avec des accents, donc en général j’inclus un meta-tag pour que le navigateur interprète correctement les accents. Ca marche bien dans les pages standard, mais pas pour le site de ma fille. En effet tout le contenu du site est chargé ou rechargé après l’interprétation du meta tag par le navigateur, donc le navigateur ne recharge pas la page… donc ne traite pas les accents et autres caractères bizarre comme il devrait.
La solution est donc avant affichage du contenu, de remplacer tous les caractères spéciaux par leur valeur en HTML… pour le français ça va c’est pas trop long, le nombre de caractères spéciaux est limité, mais pour les langues plus exotiques, comme le bulgare, le japonais, le thailandais? comment que c’est ti qu’on fait, hein???
Si vous avez des pistes je suis preneur.