Babozor’s Blog

Source: http://ajaxian.com/archives/catching-users-javascript-…-logs

Récupérer les erreurs Javascript sur les log de votre serveur

Markku Uttula a admis coder en étant bourré and a décidé d’écrire un petit hack qui capture les erreurs javascripts et les envoi à ses fichiers de log sereveurs en utilisant Ajax.

Vous aimeriez en faire autant? Peut être pour améliorer vos tests utilisateurs de votre framework?

Babozor:
Effectivement, utile… pour un debuggage optimal

Source: http://ajaxian.com/archives/yahoo-releases-instant-search

Yahoo lance “Instant Search” (Recherche Instantanée)

Utilisant quelques unes de leurs technologies maison, Yahoo lance son outil de recherche instanée, qui affiche les résulats en même temps qu’on tape les mots cherchés.

Le service est toujours en version Beta (qui ne l’est pas ces jours ci?), donc avec un nombre de fonctionnalités limité. Il y a quelques fonctionnalités intéressantes, qui pourait donner des leçons à Google. Essayez d’aller sur cette page et de rechercher une adresse. Une boite aparaît avec un mini-plan. Vous pouvez accéder à une carte plus grande ou avoir l’itinéraire pour y aller. Tapez “paris weather” (temps paris) et vous avez une information sur le temps qu’il fait avec des liens pour obtenir plus d’informations.

Pour ceux qui utilisent une page du type search.yahoo.com, vous pouvez décidez d’utiliser l’Instant Search par défaut, en le mettant dans vos préférences. Pour ceux qui veulent plus d’information sur c=le moteur de recherche et en parler avec d’autres utilisateur, vous pouvez aller sur leur forum.

Babozor:
Le service de recherche instantanée est assez blufant, il marche bien, de temps en temps un peu lent à la détente… on peut aussi regretter le manque de message quand Instant Search ne trouve rien, mais… comme ils le disent c’est encore une version Béta.

Source: http://ajaxian.com/archives/prototype-easing-ajaxs-pain

Prototype: Simplifier Ajax

Si vous commencer dans le vaste monde d’Ajax, vous vous demandez surement pourquoi tant de monde utilise quelque chose d’aussi difficile que la connexion XMLHttpRequest. Bien sûr, Ajax n’aurait pas eut le même succès si tout le monde avait dû son code à chaque fois. Entrez dans le monde d’une des librairies JavaScript les plus populaires, avec support Ajax: Prototype.
Vous ne l’avez jamais utilisé? Voila un article pratique qui vous permettra d’accélérer votre première implémentation.

“
Cet article décrirt Prototype, une librairie JavaScript OpenSource, pour créer une application Ajax. J’ai expliqué comment utiliser Prototype pour la mise en place d’un application qui affiche le niveau annuel de CO2. En premier, je vais parler des bénéfices de Prototype et comment installer Prototype dans votre application. Ensuite je rentrerais plus profondément dans le code, et comment bien utiliser cette librairie.
“
Quand on apprend un nouveau langage ou style de codage, c’est toujours plus simple d’avoir un but à atteindre. Dans cet article ils commencent du début (avec une petite partie pour la configuration) et vous introduisent Prototype et ses fonctionnalités. Vous aurez besoin d’un petit background en JavaScript, mais rien de très méchant.

Source: http://ajaxian.com/archives/dominclude-replacing-pop-ups

DOMInclude: Remplacer les pop-up

DOMInclude est une librairie qui permet d’ajouter du contenu dyanmque en ligne plutôt que d’utiliser des pop-up.

“
Les fenêtres pop-up sont une gêne aussi bien pour les développeurs que pour les utilisateurs. Bien souvent c’est utiliser pour un lien vers un terme ou les conditions d’un document et comme le client ne doit pas quitter la page, on vous demande d’implémenter des pop-up.

Le problème avec cette technique est aussi bien technique que psychologique:
- des années de pop-up non sollicité ont conditionné les utilisateurs à fermer les pop-up dès leur ouverture
- la même raison et des problèmes de sécurité ont obligé les utilisateurs à installer des bloqueurs de popup ou modifier la configuration de leur navigateur pour les bloquer, et par là bloquerons même les ‘pop-up amicaux’.
“

Babozor:
Très bonne alternative aux pop-up… j’adore

Source: http://ajaxian.com/archives/ajax-and-your-cms

Ajax et votre CMS

Ajax et votre CMS (Content Management System=Système de gestion de conetnu) est un article écrit par Jonathan Downes et Joe Wlaker (ou DWR frame).
Les CMS font souvent l’objet de discussion dans un contexte Ajax, depuis que nous avons la possibiloté d’améliorer l’expérience CMS.
L’article détaille quelques manière d’améliorer les CMS

“
Une des choses intéressantes avec Ajax est le faites de ne pas avoir à rafraichir votre page à chaque fois que vous voulez ajouter des éléments supplémentaires à votre page. Cette fonctionnalité est souvent apellée ‘Interface page unique’ et est particulièrement utile quand un grand nombre de données sont manipulés en tâche de fond pour faire marcher une fonction. Par exemple le CMS vendor Day utilise depuis longtemps Ajax pour l’arbre de navigation, permettant une approche graphique et technique qui se différencie de l’approche tarditionnelle. Par exemple, maintenir les états de l’arbre, quelle branche est ouverte ou fermée est très difficile en HTML standard, et peu efficace pour votre réseau.
”

Source: http://ajaxian.com/archives/faster-dom-queries

Des requêtes DOM plus rapides

Dean Edwards et Alex Russel se sont creusé le ciboulot pour améliorer la vitesse sur DOM.
Alex a commencé avec un “janky hack” qui utilise votre élément favoris document.getElementById d’une mauvaise façon, en regroupant les éléments par id.
Son hack contient une version des éléments en cache.
Dean fait un petit pied de nez à la standardisation, mais il sait que c’est le prix à payer pour une travail DOM plus rapide. Il c’est amusé avec XPath au même problème et conclut:
- Les requêtes DOM sur FireFox ont l’air plutôt rapides.
- XPath est 150% plsu rapide que DOM sur des requêtes sur une plateforme Mozilla.
- Xpath est 1000% plus rapide que les requêtes DOM sur une plateforme Opera
- l’expression étudiée est 200 à 400% plus rapide sur une plateforme IE
- le comportement reste fluide.

Babozor:
Effectivement et heureusement que Xpath est plus rapide qu’un parser JavaScript… sinon à quoi bon utiliser  Xpath??

Source: http://ajaxian.com/archives/xmlhttprequest-w3c-working-draft

Document de travail W3C sur le XMLHttpRequest

La W3C a annoncé leur intention de standardiser l’objet XHR et la première version du document de travail a été dévoilée.
Qu’est ce que cela signifie pour nous? Et bien cela vous donne un peu de documentation, quelques tuyaux pour les éditeurs (grâces aux notes d’implémentation), et nous indique donc que la nouvelle requête XMLHttpRequest sera la méthode du futur (vu que cette fonction est quasi incluse dans IE7, etc…)

Babozor:
Effectivement c’est une bien bonne nouvelle tout ça

Source: http://ajaxian.com/archives/single-page-ajax-store

WebMarchand Ajax, page unique

HiDefDvd.com est un nouveau web machand qui a implémenté une application Ajax sur une page unique.
Certains éléments nous paraissent très pertinents. Ajouter un article est une opération Ajx, idem pour la wish-list. Par contre, est ce vraiment censé de cliquer sur une catégorie, voir un message de ‘loading’ et ensuite réafficher la même page? Je ne pense pas.
Pour cela, des pages séparées marchent mieux, alors ne devenez pas fou d’Ajax pour tout et n’importe quoi.

Babozor:
Je suis assez d’accord avec cette analyse. L’Ajax a des côtés très très pratiques, mais n’est pas applicable n’importe où et n’importe comment. Il n’empêche ce WebMarchand a le mérite d’être un des premiers à étreiner la technologie, et même si c’est parfois maladroit, moi je dis quand même bravo…

Depuis quelques semaines certaines personnes ont fait très justement remarqué dans certains posts que le niveau de certaines applications utilisant Ajax pouvait laisser à désirer au point de vue sécurité. Malheureusement ce phénomène n’est pas réservé à Ajax et touche beaucoup d’applications web qui sont peu ou mal sécurisés.

Nous allons donc essayer de faire le tour des différentes failles possibles et leurs réponses.

Dans la première partie nous tenterons d’expliquer les bases d’une sécurité adéquate, en reprenant la base et certains aspects fonctionnels.
Dans la deuxième partie (qui devrait arriver d’un jour à l’autre)  nous nous intéresserons plus à des cas d’écoles et à leurs solutions.

Les risques
Les risques qu’encourent une applications sont de deux types, que nous apellerons attaques belliqueuses et attaques malicieuses.
Les attaques belliqueuses sont des attaques qui tentent de prendre le contrôle ou des informations en s’attaquant directement à l’infrastructure du serveur. Ces attaques sont liés à des éventuels problèmes de sécurité de la plateforme et ne concernent en rien la programmation de l’application et nous laisserons donc nos amis les administrateurs réseaux et autres personnes de l’exploitation s’arranger avec ces attaques belliqueuses.
Les attaques malicieuses sont plus difficiles à cerner, en général elles utilisent un faille dans la programmation de l’application web pour récupérer des informations auxquelles l’utilisateur n’a pas l’accès, effectuer des créations, modifications, suppressions, etc…
Ce sont ces attaques qui sont sous la responsabilité directe du programmeur de base, qui doit s’assurrer à tout moment que les informations qu’il délivre ou les actions qu’il autorise sont bien destinées au bon utilisateur et que ces instructions ne peuvent pas être utilisés par un petit malin dans un fjord norvégien ou en plein coeur de Paris.
Quelques principes de base
Nous allons rapeller quelques principes de base, aussi bien fontionnels que techniques qui sont à suivre en toutes circonstances pour garantir un niveau minimum de sécurité à votre application web (je sais certaines recommandations paraissent idiotes, mais vous n’avez pas idée du nombre de fois où elle ne sont pas respectées).
1. ne JAMAIS mettre un mot de passe en clair dans une page (mais alors vraiment JAMAIS, vous rigolez, je le vois, mais je l’ai déjà vu… alors ne rigolez pas trop)
2. les mots de passes stockés en base doivent être hachés (ou alors cryptés, mais le mieux reste hachés)
3. les données ultra sensibles (types numéro de carte bleu, etc…) ne doivent jamais être stockés nulle part (c’est le meilleur moyen de ne jamais se les faire voler)
4. personne, pas même l’administrateur du service ne doit avoir un accès aux mot de passes et données sensibles (comme cela aucun usurpateur ne peut tomber sur ces informations…) si le client pert son mot de passe, on lui en regénère un et on lui envoi par email…
5. Si vous ne voulez pas que quelqu’un “pique” certaines informations, ne les mettez pas en ligne (je sais c’est con de dire ça, mais c’est encore la meilleure sécurité qui existe aujourd’hui)
C’est votre devoir de développeur d’avertir votre chef de projet ou votre responsable des dangers des attaques malicieuses sur votre service et donc d’imposer ces quelques règles de base simples… Si ces règles ne sont pas respectées, le reste ne reste à rien ou en tout cas pas à grand chose.
Les requêtes
Pour certains ces notions semblent couler de source, mais 90% des développeurs ne comprennent que de façon superficielle certains concepts essentiels et fondateurs du web d’aujourd’hui…
Ces notions sont très importantes, puisque c’est sur ces bases que se fonderont les attaques malicieuses et donc aussi votre technique de défense (ton kung fu très bon…)
Les échanges sur le web se basent sur le protocole HTTP.
Ce protocole est assez simple à appréhender.
Vous voulez aller jeter un oeil sur une page web, en l’occurence http://www.babozor.com/index.php
Pour faire ceci, votre navigateur va envoyer un requête au serveur qui héberge ce site web et lui demander de bien vouloir lui renvoyer la page demandée.
Cette action est donc un requêtes du client vers le serveur.
Le serveur peut répondre de divers manières, si la page est valde et que vous y avez accès, il vous renvoi le contenu de la page qui est interpréte par votre navigateur et affiché par celui ci. Si il y a un problème, le serveur renvoi un code (par exemple la fameuse 404 pour une page inconnue, etc…) qu vous renseigne sur le problème survenu.
Traditionnellement il y a 2 façons d’envoyer des requêtes vers un serveur:
- GET: vous envoyez votre requête sous la forme d’un chaine de caractère qui comprend l’url de la page et toutes les variables (par exemple http://www.babozor.com?leplusfort=babozor)
- POST: vous envoyez votre requête au serveur sous la form d’une url et d’un chaine de caractère rajouté au header de la requête qui content les variables.
Quelle différence? pour le serveur aucune ou presque, à part de rendre explicite les variables en GET dans le navigateur (le client voit les variables dans la barre d’adresse de son navigateur).

Client / Serveur
Cette notion là encore est une notion fondatrice que peu de développeur maitrisent vraiment.
Les attaques malicieuses ne viennent jamais du serveur (sinon ce sont des attaques malicieuses, et ne vous concernent plus), mais du client.
Aucune action ne peut être effectuée sur le serveur si on ne les autorise pas. Pourquoi?
Que vous utilisiez ou non un langage dynamique (j’espère, sinon ce post vous n’est d’aucune utilité), la page affichée à l’utilisateur est une page statique, générée par Apache avec l’aide de PHP… PHP ou tout autre langage web n’est qu’une sous couche du serveur web, qui aide celui ci à construire ses pages. Les pages délivrées à l’utilisateurs sont toujours statiques, il ne peut en aucun cas les modifier… c’est vous qui modifiez les pages, le client ne peut que les visualiser.
C’est un concept important à saisir.
Il est donc important de saisir la relation embivalente Client / Serveur.
Le client envoi des requêtes et reçoit des réponses, le serveur traite ces requêtes et lui renvoi des pages.
Certains contrôles basiques peuvent être effectués côté client (tel que validation d’un formulaire, par exemple), mais ces contrôles restent limités. Par exemple, on ne vérifie pas le mot de passe côté Client, puisque ça voudrait dire envoyer “en clair” le mot de passe au navigateur pour que celui ci vérifie sa validité. Un contrôle mot de passe doit toujours rester côté serveur.
Les contrôles côté client doit être limités à la comodité pour l’utilisateur…
Cette notion est d’autant plus importante à maîtriser, si vous vous lancer dans le codage d’une application Ajax, où la délimitation entre Seveur / Client devient plus floue… ce passage n’est pas nécessairement associé à une page, mais à un requête et à une réponse du serveur.

Bon je crois qu’on en a assez fait pour maintenant. Pour certains cela a du rafraichir quelques souvenirs et pour d’autres leur causer un gros mal de crâne.
Demain on s’attaque aux choses sérieuses, les attaques malicieuses et la protection contre des actions non autorisées.

Source: http://ajaxian.com/archives/speeding-up-ajax-with-json

Augmenter la rapidité d’Ajax avec JSON

La rapidité est la chose la plus importante quand on parle d’applications en ligne. Les utilisateurs détestent attendre, spécialement les plus expérimentés. En sachant cela, optimiser tout ce qui est possible dans votre application peut faire la différence entre quelqu’un qui délaisse votre service et quelqu’un qui reste et continue d’explorer votre site. Une méthode pour améliorer la vitesse de votre application est décrite sur Builder.com en utilisant JSON pour améliorer la rapidité de connexion des scripts Ajax entre ceux-ci et le serveur.

“
XML est la méthode standard déchange de donnée, mais ce n’est pas souvent la meilleure méthode. Bienque le XML ajoute une structure et des meta-data aux données, il le fait d’une façon un peu bavarde. XML dispose aussi d’une syntaxe un peu complexe, demandant l’action d’un parser qui est loin d’être trivial. En JavaScript, XML diot être parsé en utilisant une arborescence de type DOM. Et une fois l’arborescence DOM construite, vous devez aussi pouvoir la parcourir, pour créer les objets JavaScript correspondant ou alors utiliser les données XML dans votre application Web côté Client.

Heureusement, il existe une meilleur méthode
“

L’article introduit JSON au lecteur, en offrant une comparaison avec une structure XML équivalente. Leur point de vue est que le XML est très bien pour marquer les données, mais JSON permet d’accélérer les échanges de données. Un exemple est fourni de la différence pour la même requête entre XML et JSON, la solution JSON paraissant plus simple. L’article se finit sur une démonstration de la fiabilité de JSON pour votre application, et certains aspects de cette technologie côté Serveur.

Babozor:
Pas encore eut le temps de regarder plus précisément l’article en question, mais ça vaut le coup d’oeil…