Jeudi dernier se tenait le Barcamp PHP Cheese & Wine. Même si le vin et le fromage ont été très appréciés, nous n’étions pas venus (seulement) pour ça. Alors pour les absents qui ont eu tort de l’être, voici une petite synthèse de cette longue soirée.

Un vrai barcamp

Premier bon point : c’est un vrai barcamp où les participants se présentent et définissent le contenu des ateliers. Tous les barcamps ne respectent pas cette règle de base… Xavier Gorse, président de l’AFUP, a donc joué le rôle de « maître de cérémonie » pour établir le programme d’après les souhaits de chacun  :

• PHP et sécurité
• PHP 5.3
• Déploiement d’applications PHP
• PHP et les bases de données « NoSQL »
• Outillage PHP
• PHP et testing
• Frameworks PHP

Pour ma part, j’ai participé aux ateliers :

• Déploiement d’applications PHP
• PHP et les bases de données « NoSQL »
• PHP et testing

Je limite donc mon article à ces sujets, sachant que d’autres synthèses ont déjà été publiées :

• Synthèse du Barcamp PHP toulousain, par Raphaël Rougeron
• Synthèse du Barcamp PHP toulousain, par Thomas Gasc

Déploiement d’applications PHP

Cet atelier a mis en évidence la difficulté de déployer des applications web en général (technologies nombreuses et environnement hétérogène). Tous les outils existants ont été passés en revue, du paquet Linux (.deb) aux outils spécifiques à PHP (PEAR, Phing, Phar) en passant par des intermédiaires parfois plus adaptés (makefile, Puppet, Capistrano, Ant). Deux groupes de participants étaient clairement représentés, avec des besoins très différents :

• Déploiement d’une solution sur un parc important et hétérogène (cas des éditeurs de solutions, comme Linagora avec OBM)
• Déploiement d’un projet sur-mesure sur un ou quelques serveurs, mais très fréquemment et avec des contraintes d’intégration de contenus externes (cas des agences web, avec plusieurs déploiements par jour).

Dans le premier cas, la difficulté est d’identifier la configuration des serveurs cibles et de préparer les paquets d’installation correspondants (.deb pour chaque distribution Linux, .msi pour chaque version de Windows, etc.), tout en assurant la compatibilité des données sans toujours les connaître (tests de régression).

Dans le second cas, il faut savoir intégrer pendant le déploiement les données du site en exploitation (base de données, templates gérés par un web designer externe, etc.), avec d’éventuelles transformations (ETL, Extract Transform Load).

J’ai ajouté qu’un déploiement ne se limite pas à la livraison de la partie applicative mais doit aussi savoir traiter la mise à jour des outils liés au projet (plate-forme de gestion de tickets, extranet, feuille de route, tests, sauvegardes, alertes, etc.).

En dehors de PEAR, trés utilisé et qui est un outil de déploiement à l’origine, j’ai une préférence pour Ant + Phing et Capistrano.

Bases de données « NoSQL »

Là, on entre dans une autre dimension. Les bases « NoSQL » sont des bases de données non relationnelles. En gros, on ne retrouve pas le schéma habituel « tables contenant des champs et étant reliées entre elles ». L’avantage est d’obtenir des performances exceptionnelles sur des entrepôts de données énormes. Parmi les acteurs majeurs qui développent et utilisent des bases « NoSQL », on peut citer : Google (projet Big Table qui a inspiré le projet Cassandra), Facebook ou Linkedin.

Si on revient à la dure réalité d’un acteur de dimension modeste, on constate que ces technologies émergentes et prometteuses sont encore très spécifiques. Les bases relationnelles ont de beaux jours devant elles. La difficulté est notamment de réintégrer dans l’application PHP ce qui fait la force des systèmes SQL : sélection, jointures, intégrité référentielle, etc. Le volet testing des projets en prend un coup…

PHP et testing

Atelier en petit comité (6 personnes), en concurrence déloyale avec l’atelier Frameworks qui a fait le plein ! Nous avons tenté de lister les types de tests liés à une application web, en dépassant autant que possible la simple vue du développeur :

• Tests unitaires (PHP et Javascript)
• Tests fonctionnels
• Tests d’IHM (via Selenium Core, Selenium RC et Selenium IDE)
• Tests de recette
• Tests de non régression
• Tests de performance
• Tests de charge
• Tests de conformité (normes, W3C, accessibilité, etc.)
• Tests ergonomiques (tri par cartes, paper prototyping, tests utilisateurs, etc.)
• A/B testing

Les échanges sur nos expériences ont été très instructifs. Nous étions tous d’accord pour insister sur la définition précise des cas d’utilisation qui facilite la gestion des tests pendant toute la durée du projet avec le client. D’où une phase de spécifications sérieuse qui conditionne la qualité du travail livré. Certains tests peuvent faire l’objet de validation contractuelle, comme les wireframes issus de tests ergonomiques qui servent ensuite de feuille de route aux intégrateurs et développeurs.

La difficulté avec les tests, c’est de savoir placer le curseur pour ne pas s’y noyer. Il n’est pas réaliste d’appliquer les tests de façon exhaustive. C’est un idéal en contradiction avec les budgets et les délais imposés en pratique. Il faut donc savoir réaliser les bons tests, au bon endroit et au bon moment. Par exemple, sur le calcul des prix d’un panier de site e-commerce, sur l’intégration des données lors d’un couplage entre deux systèmes, sur l’ergonomie d’une interface riche, etc.

En résumé

Une excellente soirée qui a largement dépassée les 5 heures prévues ! L’accueil de Linagora et de l’AFUP était parfait, l’ambiance très sympathique et le niveau des échanges très pointu. Il y a des gens qui savent faire des choses avec PHP en Midi-Pyrénées ! Je pense qu’on remettra ça sous peu. Prochaine étape : le Bargento, lundi 9 novembre à Paris. Je serai présent avec l’équipe de l’AFUP pour organiser et animer cette journée qui s’annonce exceptionnelle. Et à la suite, le Forum PHP 2009, tout aussi exceptionnel. Sur ce coup-là, je déclare forfait. Il faut bien travailler un peu !

Même s’ils sont ultra-surveillés et protégés, les 13 serveurs racines qui gèrent tous les noms de domaine d’internet, étaient également potentiellement concernés.

Au fait, à quoi sert un serveur de noms de domaine ? Tout simplement à faire le lien entre un nom de domaine et une adresse IP (et inversement). Chaque machine branchée sur internet possède une adresse IP qui permet de la rendre unique sur le réseau mondial. Cependant, utiliser une adresse IP ne suffit pas. D’abord, elle n’est pas facile à retenir. Et puis, comment feraient les utilisateurs de Google qui exploitent 450.000 serveurs ? Il est plus simple de taper www.google.com dans son navigateur que 64.233.167.99. Même si ça marche, évidemment (si, si, essayez !).

Le serveur de noms de domaine est donc un maillon indispensable d’internet. Quand il s’arrête, vos services internet aussi…

Bref, hier, tout le monde était sur le pont… et moi avec ! Si vous gérez un serveur DNS, n’attendez plus, mettez à jour votre installation, c’est vital ! Le correctif est publié et disponible pour pratiquement tous les systèmes.

Depuis 2004, on sait que MD5 n’est plus très sûr. Cependant, casser cet algorithme n’est pas à la portée de tout le monde. Aucun risque pour vos bases de données utilisateurs ? C’est sans compter sur les bases de hash MD5. Leur but : stocker des chaînes de caractères et leur hash. Comme les utilisateurs entrent souvent des mots communs ou connus, il est très simple d’interroger ces bases pour obtenir la liste des chaînes de caractères compatibles avec un hash MD5. GData en est un exemple particulièrement efficace et complet.

Vous voulez connaître le mot de passe caché derrière le hash MD5 fe01ce2a7fbac8fafaed7c982a04e229 ? Le voici en 1/10^e de seconde : demo. Et celui-ci, assez fréquent dans les bases mal paramétrées : 21232f297a57a5a743894a0e4a801fc3. C’est admin !

Il est temps de changer de méthode de cryptage…

Source : Nexen

Pas très réjouissant comme cadeau de fin d’année… L’essentiel est qu’Askimet ne croûle pas sous la charge ! Mais, connaissant les critiques récurrentes sur la vulnérabilité de WordPress face aux spams, sauvé comme par miracle par l’extension Askimet… du même éditeur, c’est peut-être là qu’est le défi que souhaite relever quelques spammers.

Qu’ils aillent jouer ailleurs !

MySQL Proxy, proposé par MySQL AB, est le genre d’outils dont le rôle semble si évident qu’on se demande pourquoi il n’existait pas avant. Comme tout proxy, il récupère les requêtes destinées à la base de données, effectue des traitements et adresse une requête modifiée au serveur MySQL. Bien entendu, l’opération inverse est aussi gérée : MySQL Proxy sait récupérer un résultat de requête et le transformer avant de l’adresser au client initial.

Fonctionnalités

Après cette petite présentation, on peut se demander pourquoi on aurait besoin d’un proxy, puisque les services applicatifs (s’ils sont correctement architecturés et codés…) devraient envoyer une requête optimisée au serveur MySQL. Une petite liste des fonctionnalités finit par convaincre de son intérêt :

• Analyse des requêtes
• Filtrage et modification des requêtes et des résultats
• Injection de requêtes
• Load balancing
• Exécution de scripts (basés sur le langage LUA)

Cas d’utilisation

Dans la pratique, on peut imaginer les situations suivantes :

• Corriger les erreurs de syntaxe communes.
• Garantir le fonctionnement d’anciennes applications utilisant des requêtes non supportées.
• Supprimer du résultat un mot de passe demandé dans la requête.
• Récupérer et fusionner avec le résultat des données externes à la base de données (fichiers, flux XML, RPC…)
• Router les requêtes vers un autre serveur MySQL ou vers une autre base de données du même serveur.
• Empiler un lot de requêtes et les contrôler avant de mettre à jour les tables.
• Dupliquer les requêtes en temps réel sur deux bases différentes.
• Exécuter un script shell avant ou après des modifications dans la base de données.
• Interdire certains motifs de requêtes.
• Verrouiller des tables selon le contexte.
• Contrer les injections SQL non désirées.

On le voit, les possibilités sont infinies et ne dépendent que des contextes de production et de l’imagination des développeurs. MySQL Proxy permet surtout d’éviter d’intégrer la gestion de l’exploitation des bases de données MySQL dans les services applicatifs. Voilà enfin une saine séparation du travail du développeur métier et de l’administrateur MySQL !

Mise en oeuvre

MySQL Proxy est encore en version alpha et son fonctionnement n’est garanti que pour les versions MySQL 5.0.x et ultérieures.

Pour découvrir ses possibilités, O’Reilly Network propose un didacticiel clair et très fourni : Getting Started with MySQL Proxy.

Source : Linuxfr.org

Tout serveur qui se respecte doit donc être entouré de quelques précautions :

• composants sélectionnés pour leur qualité
• double-alimentation stabilisée
• installation en salle blanche climatisée
• gestion des disques sécurisée (avec RAID par exemple)
• sauvegardes complètes et incrémentales
• ubiquité des données
• sécurisation des accès
• surveillance et alertes
• procédures d’urgence et de récupération
• tests et validation des applications et services
• etc.

Ce qui est moins marrant, c’est quand vous avez presque tout prévu et que le « presque » casse la machine. Comme dirait le marketing d’IBM, « la sécurité de votre système d’information repose sur son maillon le plus faible ».

Pourquoi je vous explique tout ça ? Parce que, malgré toutes les précautions (enfin presque…), j’ai vécu un scénario catastrophe ce week-end. L’objet du stress : un joli serveur dual-core sous Windows Server 2003 monté en RAID 1 qui gère l’informatique de 65 personnes. Une belle bête, donc.

Sauf que la machine a eu une faiblesse et que les procédures d’intervention n’étaient pas adaptées. Résultat : perte de la partition système… et aucune sauvegarde exploitable !

C’est alors qu’entre en scène Ultimate Boot CD et sa panoplie d’outils incroyables. Grâce à lui, j’ai pu récupérer la partition perdue, la cloner sur un autre disque, en vérifier le fonctionnement, puis recréer le master boot record.

Comme les données étaient sensibles et qu’on ne peut pas se permettre d’utiliser autre chose que des outils professionnels réalisés par des professionnels, j’ai aussi tenté l’aventure avec les outils et procédures de Microsoft (notamment la console de récupération du CD d’installation). Résultat : échec total…

Avec un été aux allures d’automne, j’ai eu envie de présenter un flux migratoire d’exception. Nul discours écologique dans mes propos, puisqu’il est question de PHP, le langage le plus répandu pour créer des applications web. Entre la mort de PHP4, la gestation de PHP6 et PHP5 qui tarde à s’imposer, voici un point sur la situation, les enjeux… et les risques.

PHP4 en fin de course

C’est maintenant officiel, PHP4 ne sera plus supporté à partir du 1^er janvier 2008. En soit, l’annonce ne choque pas puisque PHP5 a pris le relais depuis 3 ans. Mais, sur le terrain, la percée de la version actuelle de PHP est moins évidente. En cause, les nombreuses applications PHP4 encore exploitées en ligne qui freinent les hébergeurs dans l’adoption de PHP5.

Migrer de PHP4 à PHP5

Sachant que la migration de PHP4 vers PHP5 devient obligatoire, comment la réaliser en douceur dans le temps imparti (5 mois) ?

Premier point : s’informer et comprendre la nécessité de migrer. Le site Go PHP5 est là pour ça !

L’initiative Go PHP5 pour promouvoir une migration rapide vers PHP5.

Ensuite, il faut mettre le nez dans l’existant et y apporter les corrections ou les évolutions nécessaires pour le rendre compatible avec PHP5. On s’aidera des ressources mises à disposition par le PHP Group :

• Migration de PHP 4 à PHP 5
• Migrating from PHP 5.0.x to PHP 5.1.x
• Migrating from PHP 5.1.x to PHP 5.2.x

Préparer l’arrivée de PHP6

Maintenant, quid de PHP6 ? Quitte à migrer cet automne, autant en profiter pour préparer son arrivée ! On sait maintenant à quoi ressemblera la nouvelle mouture PHP et ce qu’elle implique pour les développeurs.

A la lecture de Prepare for PHP 6, on remarque vite que PHP sera beaucoup moins permissif. On ne regrettera pas le Register Globals, ni le Safe Mode (même s’il peut gêner quelques hébergeurs à la traîne).

Bien sûr, l’abandon des Magic Quotes imposera de retoucher de nombreuses applications PHP4 pour éviter les injections de commandes (pour attaquer une base de données, par exemple). On me rétorquera que PHP5 les désactive par défaut… ce qui veut dire qu’on peut les activer pour éviter de « perdre » du temps à mettre en conformité son code ! Avec PHP6, point de salut, il faut s’y coller !

Parmi les fonctionnalités les plus attendues, les namespaces pour la programmation orientée objet, le support natif d’Unicode, l’accélérateur APC par défaut.

Le plus inattendu est sans doute goto pour spécifier où continuer l’exécution du code ! A oublier de suite en programmation orientée objet…

Après le discours, la pratique. Voilà une petite check-list (tirée du magazine Programmez, juin 2007) pour faciliter l’arrivée de PHP6 :

• Ne pas utiliser register_globals, mais $_POST, $_GET, $_COOKIE et $_REQUEST
• Ne pas utiliser $HTTP_POST_VARS et $HTTP_SERVER_VARS, mais $_POST et $_SERVER
• Mettre les directives magic_quotes_* à off
• Ne pas spécifier le passage par référence dans l’appel de fonction, mais dans le prototype
• Ne pas utiliser la fonction __autoload() (pratique mais très gourmande)
• Ne pas mettre une variable derrière un break, mais une constante, un nombre… ou rien
• Désactiver le safe_mode
• Ne pas utiliser la librairie GD1 pour traiter les images, mais la GD2
• Utiliser l’UTF-8 ou l’UTF-16

Le dernier point est, selon moi, le plus critique. Le support d’Unicode (UTF-8 ou UTF-16) impose de convertir la chaîne complète du développement : fichiers de code source, fichiers de données, base de données, navigateur web, etc. Or le support d’Unicode est loin d’être un réflex dans les projets web. Quel webdesigner se préoccupe de déclarer le support de l’Unicode dans Dreamweaver ? La question qui suit est : pourquoi la majorité des outils propose encore l’ISO-8851 ou CP1252 par défaut ? Bref, ce point dépasse le cadre des évolutions de PHP, mais deviendra un vrai Capharnaüm s’il n’est pas traité dans son ensemble.

Une opportunité pour les entreprises… et leurs prestataires

Inutile de tourner autour du pot : la migration nécessaire de PHP4 vers PHP5 demandera d’ici la fin de l’année un certain travail aux équipes de développement PHP de tous bords. Pour le bien des entreprises, c’est certain. Elles verront leur système d’information évoluer et gagner en maturité. Pour leurs prestataires aussi qui sauront profiter de l’opportunité pour aller plus loin qu’une simple mise en conformité iso-fonctionnelle.

Pour commencer, rien ne vaut un exemple très démonstratif. Nous nous croyons tous assez malins pour éviter les pièges, mais il est extrêmement simple de tomber dans le panneau, surtout si nous sommes en confiance.

L’erreur de Neuf Cegetel

Neuf Cegetel propose à ses clients un espace pour gérer leur compte. Ce service est accessible à l’adresse espaceclient.neuf.fr, indiquée au dos des factures.

Jusque-là, rien de plus classique. Sauf que sur certaines factures, l’adresse indiquée comporte une erreur : à la place de espaceclient.neuf.fr, on lit espaceclientneuf.fr. Subtile différence que des petits malins ont exploitée !

L’exploitation de la faille

Le client qui entre l’adresse indiquée sur la facture, se sent parfaitement en confiance. Pourtant, le site qu’il voit n’appartient pas à Neuf Cegetel.

Le vrai site.

Le faux site.

Vous allez me dire que les deux sites ne se ressemblent pas vraiment et qu’il est difficile de se laisser tromper. Oui, pour les clients qui utilisent souvent ce service, c’est évident. Mais combien d’autres ne vont le consulter qu’en cas de problème ? Pour ceux-là, impossible de repérer l’arnaque au premier coup d’oeil ! D’autant que les libellés de certains liens sont en parfaite adéquation : Mon compte, Ma facture, Service client, Assistance…

Après avoir cliqué sur deux ou trois liens, l’utilisateur se rendra vite compte qu’il y a anguille sous roche et passera par le site officiel de Neuf Cegetel pour retrouver l’Espace client.

Ce petit jeu de cache-cache aurait pu être tout autre. Imaginez un faux site parfaitement identique au vrai. Vous souhaitez consulter votre facture, vous entrez votre identifiant et votre mot de passe… Scénario catastrophe !

Un détournement (presque) légal

Cependant, cet exemple n’est pas un cas de phishing. Ici, tout est légal (si ce n’est l’abus de confiance que Neuf Cegetel pourrait porter devant les tribunaux). N’importe qui peut déposer et exploiter le domaine espaceclientneuf.fr. Et donc profiter des erreurs de frappe.

Mais où est le profit ? Simplement dans les revenus tirés des liens sponsorisés, placés dans les pages du faux site. Avec quelques millions de clients Neuf Cegetel, les revenus peuvent s’avérer très juteux… sans rien faire d’autre qu’acheter un domaine.

Nous entrons dans l’univers très fructueux des domainers qui sera le sujet de mon prochain article…

Internet, c’est génial ! On y trouve de tout et pour tout le monde ! Mais aussi le meilleur… comme le pire.

L’association E-enfance diffuse deux films très efficaces pour sensibiliser les parents aux dangers d’internet. Deux films courts, à la chute brutale, à l’image de ce que les enfants vivent sur le web : le plaisir de découvrir peut virer au cauchemar en un seul clic…

Cette opération me rappelle celle effectuée par le National center for missing and exploited children :

Un jour, je l’espère, ces spots ne seront plus utiles…

Merci à Gilles Klein pour l’information.

Dossier du Journal du Net

Un projet de décret pour surveiller le Web participatif et contributif :

FAI, hébergeurs et éditeurs de site ou auteurs d’un blog ouvert aux contributions des internautes devront bientôt stocker une multitude d’informations concernant les internautes. Adresses IP, informations bancaires et civiles, mais aussi pseudos utilisés sur les forums, mots de passe et questions secrètes devront être collectées et laissées à disposition des juges et de l’Etat. Surtout, les hébergeurs, éditeurs de site et blogueurs pourraient être obligés de conserver la trace de chaque version de contenus créés et modifiés par les internautes.

[...]

Objectif : permettre à l’autorité judiciaire ou administrative de remonter jusqu’à l’auteur d’un propos délictueux, ou suspecté, par exemple, de représenter un risque pour la sécurité de l’Etat.

[...]

Un hébergeur aura obligation de connaître la nature de chaque modification faite sur un site.

[...]

Le Groupement des éditeurs de services en ligne (Geste) s’en inquiète. [...] L’association a fait valoir que les coûts de stockage, s’il tant est qu’il est possible techniquement, entraîneraient entre plusieurs centaines de milliers et un million d’euros de perte nette à chaque éditeur.

[...]

Un internaute pourra être poursuivi, en théorie, 4 ans après avoir publié un contenu sur Internet, sans même connaître les raisons pour lesquelles ces informations ont été recueillies.

Le dossier comporte un document PDF avec le texte du décret.

Le Monde.fr

Polémique sur la rétention des données informatiques par Stéphane Foucart :

La version de travail, que Le Monde a pu consulter, fédère contre elle les associations de défense des libertés et les industriels du secteur.

[...]

Le texte semble trop vague aux acteurs économiques du secteur, qui redoutent d’avoir à conserver l’intégralité des modifications apportées à un contenu.

[...]

L’association Iris rappelle que ces données peuvent être demandées dans le cadre « d’enquêtes administratives et non judiciaires » – c’est-à-dire menées hors du contrôle d’un magistrat.

L’Etat veut-il tuer Internet en France ? par Philippe Jannet (président du Geste) :

Cette mesure ne pourrait que déclencher une défiance immédiate des Français à l’égard de leur téléphone mobile ou fixe, comme à l’égard des acteurs français d’Internet, assassinant instantanément l’économie numérique française.

[...]

De l’avis unanime des spécialistes, c’est économiquement et techniquement impossible. Même les Etats-Unis de George W. Bush et leur « Patriot Act » post-11-Septembre n’ont jamais envisagé pareille conservation ou réglementation, qui soulèverait sans doute l’opinion publique américaine d’aujourd’hui, mais s’opère sans bruit en France.

[...]

Des données récoltées sur la base de requêtes administratives initialement motivées par la prévention du terrorisme pourraient se retrouver dans le dossier d’un juge d’instruction en charge d’une affaire de droit à l’image, de diffamation ou de contrefaçon, par exemple, sans que les personnes mises en cause par des traces informatiques vieilles de 4 ans, puissent connaître – ni contester – l’origine ou la pertinence de ces données, ni le contexte dans lequel elles avaient été recueillies, en dehors de toute procédure judiciaire, sans magistrat ni contradictoire, quatre ans auparavant.

[...]

Sous prétexte de lutter contre la menace réelle du terrorisme, l’Etat français prend – comme aucun autre – le risque de tuer une part non négligeable de l’avenir du pays, sans aucun état d’âme et dans le silence assourdissant d’une campagne présidentielle omniprésente sur Internet, mais muette sur le développement de l’Internet.

Une synthèse

Christian Fauré :

Ce qui émeut le plus Philippe Jannet, en tant que président du GESTE (TF1, Google France, M6, Skyrock, la presse en ligne, etc.), c’est que ces acteurs français de l’Internet vont devoir financer cette traçabilité pour le compte de l’État. L’article du Monde pourrait laisser croire que le GESTE s’inquiète de la confidentialité des données et des pratiques de ses clients : il n’en est rien.