Je vais commencer ce billet en souhaitant à tous une excellente année, pleine de code bien indenté et de non-régressions 
Il est temps de faire un petit point sur les évènements techniques marquants dans le domaine du développement web en 2007, et de jeter un oeil sur ce que cette nouvelle année nous apportera.
Voici une petite subtilité de MySQL. Les accents dans des champs texte peuvent être mal pris en compte dans les ORDER BY, suivant l’encodage utilisé.
Prenons l’exemple d’une table avec un champ id et un champ texte au format latin1_bin :
| id | texte |
| 1 | Crète |
| 2 | Croatie |
| 3 | Critère |
Prenons maintenant une requête standard :
SELECT id, texte FROM matable ORDER BY texte
Ceci renverra Critère, puis Croatie, et enfin Crète, car latin1_bin effectue des comparaisons binaires et est donc sensible aux caractères accentués. Heureusement, MySQL fournit une parade avec COLLATE, qui permet de convertir dans le champ dans l’encodage de son choix, on peut donc dans notre cas utiliser latin1_swedish_ci qui reconnait correctement les accents (un é est considéré comme équivalent à un e).
La requête donne donc :
SELECT id, texte FROM matable ORDER BY texte COLLATE latin1_swedish_ci
Par le biais d’AJAX, l’utilisation intensive du Javascript a permis de soulever de nombreux problèmes de mémoire au sein des navigateurs du marché. Ni IE, ni Firefox ne sont épargnés par ce sujet qui empoisonne la vie des développeurs web. Petite explication de texte.
Les fonctionnalités natives des navigateurs sont en passe de rattraper leur retard sur les extensions multimedia comme Flash.
Dans le cadre d’un petit projet perso, j’ai voulu reproduire une version Ajaxifiée d’iTunes. Le première phase consistant à contruire le modèle de données, il était nécessaire d’utiliser quelque chose de suffisamment performant pour que des requêtes sur la bibliothèque réagisse correctement - lors de l’autocomplétion dans le champ de recherche notamment.
Ils l’ont fait ! Un an après l’annonce du partenariat entre Zend et Microsoft, une version de l’extension FastCGI pour IIS6 est disponible. Cela rend donc possible l’hébergement d’applications PHP sur des serveurs Windows 2003 sans se demander si le serveur va dégager de la fumée noire. Andi Gutmans de Zend affirme avoir des performances similaires entre les versions Linux et Windows, ce qui augure du bon - même si un peu plus de transparence sur les versions utilisées serait sympathique.
Petit rappel sur la technologie FastCGI. A l’origine, la technologie CGI exécute un php.exe à chaque requête ce qui donnait des perfs catastrophiques. FastCGI consiste à conserver ce processus ouvert afin d’accélérer le mouvement (d’où le “fast”) mais cela restait assez instable sous Windows.
Cette collaboration montre en tout cas la bonne volonté de Microsoft d’aider cette technologie, et peut laisser entrevoir des perspectives intéressantes. Des initiatives comme Phalanger pourraient laisser planer une intégration de PHP dans .Net à moyen terme ?
Démarré voilà déjà deux ans, Aptana vient de passer en version 1.0. La version beta que j’avais eu l’occasion d’utiliser il y a 1 an était déjà très prometteuse, et durant ce laps de temps les IDE web basés sur Eclipse ont pris leur envol comme Eclipse PDT, Eclipse RAP…
Une bonne nouvelle postée sur le blog des développeurs d’IE ce matin : les contrôles ActiveX via des éléments object, embed etc. n’auront plus cet ignoble “cliquer pour activer”. Ce sont les suites de cette bataille juridique ridicule entre Eolas et Microsoft sur la manière d’embarquer des composants tiers dans un navigateur.
Le plugin Flash en particulier, qui est sûrement le contrôle le plus utilisé par les personnes sous IE, sera le premier bénéficiaire de ce reparamétrage à partir d’avril 2008.
En attendant c’est toujours la bonne vieille méthode qui prime : ajouter le contrôle dans la page avec un Javascript
Une des craintes qui remonte régulièrement de la part des mes interlocuteurs clients sur les applicatifs AJAX concerne leur sécurité. En effet, l’idée reçue voudrait qu’en raison des traitements effectués principalement côté client, la sécurité s’en trouverait réduite. Nous allons voir ici qu’il n’en est rien, si les bonnes pratiques techniques sont respectées.
Client-serveur AJAX
Il est important d’ouvrir tout d’abord une parenthèse sur AJAX et son mode de fonctionnement.
Il s’agit d’un design de client-serveur web très classique reposant sur du HTTP. Le format d’échange passant via le tuyau tend vers les deux mêmes standards, JSON et XML.
Les différences concernent principalement :
Au final, les données transitent de la même façon que pour des pages classiques, seuls leur format et le traitement par le navigateur changent.
Actions à entreprendre
Côté serveur, il faut respecter scrupuleusement les bonnes pratiques de sécurité d’un applicatif classique :
Côté client, la subtilité supplémentaire est que le contenu n’est pas du HTML à rendre directement dans le navigateur. Ici encore, la cohérence des données entrantes est primordiale. Vous vous devez donc de contrôler proprement et d’assainir si nécessaire ce qui est renvoyé par le serveur, contre des attaques potentielles (injection de HTML fraudulueux par exemple).
Edit : un excellent article paru sur Ajaxian aujourd’hui traite concrètement des problèmes de sécurité sur les applicatifs Web. A lire absolument.
Vous en avez marre de l’horrible console de Yahoo qui fait ramer la page en mode Debug ? Voici un petit bout de code qui redirige la fonction YAHOO.log() dans la console de Firebug.
Lire la suite »
Commentaires récents