Un proxy qui annule l’authentification, pourquoi pas ?

Le contexte

Voilà une idée bien saugrenue, je vous l’accorde. Pour comprendre, voyons un peu le contexte.

Nous avons développé une application iPhone pour HotelHotel (le site sur lequel je travaille). Elle fonctionne en interrogeant notre API interne pour effectuer des recherches d’hôtels. L’API interroge nos partenaires compare les prix et compose une liste de résultats renvoyée à l’application iPhone.

Pour les hôtels, nous disposons de plusieurs photos, qui aident à se faire un avis sur les hôtels proposés. Ces photos sont gérées par nous mêmes, nous indiquons juste leur URL à l’application distante.

Jusqu’à ces derniers jours, nous stockions ces photos sur notre propre serveur, mais pour différentes raisons, nous les avons déportées vers le service Amazon S3. Il y a plein d’avantages à utiliser ce service : haute disponibilité des contenus, bande passante très importante, pas de soucis de croissance de l’espace utilisé, … pour un coût très raisonnable.

Nous avons donc modifié les différentes parties de notre système pour que les fichiers soient placés sur Amazon S3 et les URL renvoyées aux navigateurs, application iPhone, … soient celle sur Amazon S3 et plus sur notre serveur.

Le problème

Jusqu’ici tout va bien, ou presque. Nos différents sites web (public, admin, …) fonctionnent bien, en lecture comme en écriture. Pa contre, l’appli iPhone plante et quitte dès qu’on veux charger une photo.

Après une séance de debuggage un peu déconcertante, on fini par trouver la source du problème. Pour bien comprendre, je rembobine un peu.

Pendant la phase de développement de l’appli iPhone, nous utilisions une version privée de l’API, sur un sous-domaine spécial, protégé par une authentification HTTP Basic. Juste avant la publication sur l’AppStore, nous avons changé le réglage pour pointer sur l’API de “production”, mais nous avons oublié d’enlever les en-têtes d’authentification.
On ne s’en est pas rendu compte car le serveur de production les ignorait. Il n’en attendait pas donc peu importe, il laissait tout passer.

Maintenant que les URL des images sont chez Amazon S3, et plus chez nous, ce sont leurs serveurs qui reçoivent les informations d’authentification. Manque de bol, leur serveur HTTP n’aime pas du tout les authentification de type HTTP Basic et il renvoi systématiquement une erreur 400 (Bad Request). Le contenu de la réponse est quant à lui une portion XML indiquant plus d’infos sur la requête, et c’est probablement ça qui fait planter l’appli. La librairie utilisée n’arrive probablement pas à gérer un contenu XML au lieu d’un contenu image.

Corriger l’appli iPhone pour supprimer l’authentification est très simple, mais il faut ensuite soumettre une nouvelle version à Apple (plusieurs jours de délai pour la valider) puis attendre que l’extrême majorité de nos utilisateurs mettent à jour l’appli, … Ce délai n’était pas envisageable.

La solution

Il m’est donc venue l’idée bizarre de mettre en place un moyen d’intercepter les URL demandées par l’iPhone, de les nettoyer des en-têtes d’authentification et de les transmettre à Amazon S3.

La mise en œuvre a été simple et rapide (grâce à l’aide de Grégory Colpart de Evolix). Nous avons créé un VirtualHost Apache sur un sous-domaine, dans lequel nous avons paramétré un reverse proxy. Toutes les requêtes envoyées à ce sous-domaines sont transmises de manière transparent à Amazon S3, et la directive RequestHeader supprime les en-têtes d’authentification.

Voilà la config du VirtualHost :

    <VirtualHost *:80>
      ServerAdmin webmaster@example.com
      ServerName s3tmp.example.com

      ProxyRequests Off
      <Proxy *>
        Order deny,allow
        Allow from all
      </Proxy>  

      ProxyPass / http://s3.example.com/
      ProxyPassReverse / http://s3.example.com/

      RequestHeader unset authorization
    </VirtualHost>

NB : “s3tmp.example.com” est le sous-domaine du proxy, “s3.example.com” est un alias vers Amazon S3

Lancement d’HotelHotel.com

Et voilà c’est le jour J

Après des mois de travail pour toute une équipe et un premier prototype (Wishbed pour ceux qui l’ont connu et essayé), Hotel Hotel fait sa sortie au monde ;-)

Le but est double :

1. proposer une recherche d’hôtel en ligne différente : plus d’hôtels sous la main, plus de chambres disponibles et les meilleurs prix.
2. apporter une information plus riche sur des destinations choisies : articles sur les villes, analyses complètes de ce qui se dit sur les hôtels (points positifs et négatifs, …)

C’est une première version. On a mille idées géniales à suivre, mais on ne voulait pas attendre plus longtemps pour bouleverser l’existant.

Faites le tour, essayez le, et surtout réserver des chambres d’hôtels. Vous verrez qu’on va vraiment vous aider à réduire vos frais d’hôtels !

Allez donc découvrir cette première version sur HotelHotel.com.

Vous nous trouverez aussi sur Twitter et sur Facebook.

Club de lecture – épisode pilote

Il y a quelques semaines, j’ai évoqué mon idée d’organiser un club de lecture technique. Sur mon blog et “dans la vraie vie” j’ai eu plutôt des bons retours de personnes qui en résumé veulent bien tenter l’expérience pour voir ce que ça peut donner.

La plupart des questions que je posais lors de l’exposé de mon idée n’a pas trouvé de réponse à cette heure, mais c’est pas grave, on va se lancer avec le bon sens comme point de départ — enfin le mien donc j’espère que c’est le bon.

Quelle date ?

Je propose donc le vendredi 30 avril à partir de 17h30, jusqu’à 18h30-19h.

Ça n’est qu’une proposition et il y a finalement peu de contraintes sur la date, à part l’idée à laquelle je tiens, qu’il faut que ne ça soit pas sur du temps personnel, mais plus sur du temps de boulot. Je vous renvoie à mes arguments sur la question si besoin.

Si vous êtes intéressé(e) mais que la date pose un problème, dites le en commentaire, on trouvera ce qui convient le mieux.

Quel livre ?

J’ai bien dans l’idée d’aborder des sujets assez avancés : certaines techniques de programmation, d’organisation des projets, … mais ça me paraissait risqué de partir trop vite, trop fort. Il suffit que le sujet soit trop axé sur tel ou tel langage ou approche pour que les timides soient refroidis et que la sauce ne prenne pas.

J’ai donc cherché un sujet qui concerne tout le public, à savoir les geeks intéressés à découvrir de nouvelles pratiques : innovation techno, optimisation des méthodes et perfectionnement des outils.

J’ai dit que ça n’était pas “mon” club de lecture, même si j’en suis à l’origine, donc je propose 2 livres, bien différents. Ceux qui souhaiteraient participer n’ont qu’à donner leur avis, on choisira en fonction.

Getting Real par 37signals

Getting Real expose les concepts de l’équipe de 37signals sur le travail d’une équipe qui produit une application web. De l’émergence de l’idée, jusqu’au marketing et support client en passant par la conception, le financement, la création des interfaces, le développement du code et l’organisation de l’équipe qui porte le projet.

C’est un ensemble de très courts essais, illustrant chacun une idée simple, organisés en chapitres cohérents. Ça se lit très vite (160 pages de 200/300 mots chacune). Il m’a suffit de 4 à 5 heures de lecture pour le boucler, et je ne lis pas vite.

Même si je conseille évidemment à tout le monde de lire la totalité du bouquin, je propose qu’on se focalise sur les chapitres “Priorities” et “Feature Selection” (pages 37 à 58).

Outre les versions PDF et papier qui sont payantes, il existe une version gratuite en ligne. http://gettingreal.37signals.com/

Progit par Scott Chacon

Progit détaille le fonctionnement de Git, un système de contrôle de version, depuis les concepts de bases du versionning jusqu’aux dernières subtilités d’utilisation de ce formidable outil qui change la vie de ceux qui l’utilisent.

C’est un livre écrit par une des personnes qui connaissent le mieux Git — Scott Chacon — guru de Git chez Github. Ses talents de pédagogue et la qualité du contenu font de Progit un livre clé pour appréhender le vaste sujet du contrôle de version. Les chapitres sont focalisés et concis, illustrés de séquences de lignes de commande et d’illustrations.

Je propose de se focaliser sur un seul chapitre à choisir entre “Git Branching” et “Distributed Git“. Les deux sujets sont très différents et méritent chacun une pleine discussion.

Le livre existe en version PDF et papier chez Apress, mais il est également disponible gratuitement en ligne (HTML ou sources). http://progit.org/

Au Choix

Je suis très attaché aux 2 sujets et j’y trouve autant d’intérêt, mais ça n’est pas forcément le cas de tout le monde.

Getting Real cible tous les profils dans une entreprise qui développe des produits en ligne, mais n’est pas strictement un sujet technique.

Progit est beaucoup plus orienté développeur mais quels que soient les produits qu’on développe, Git change tellement la vie que c’en est un sujet incontournable.

Je vous propose donc de donner votre avis, surtout si l’un ou l’autre des sujets vous ferait venir à coup sûr ou au contraire zapper la première.

Ruby et Rails ou bien PHP et Symfony ?

Dans le cadre de mon travail chez Autrement, je bosse principalement sur du développement web en Ruby, avec l’aide du framework Ruby on Rails.

Je suis focalisé sur le développement d’une appli web (encore un eu secrète pour le moment), mais là, Autrement édite par ailleurs le site web chambresapart.fr
Le développement de ce site a commencé bien avant que je rejoigne l’équipe et il s’appuie sur le framework Symfony, basé sur PHP.

Actuellement l’équipe Chambres à Part se compose de 2,5 personnes qui sont toutes les 3 des développeurs confirmés, spécialisés sur PHP / Symfony.

Avant le lancement de la “version 1″ de Chambres à Part, j’ai participé au développement de certaines fonctionnalités, mais principalement sur des aspects HTML, CSS, Javascript, cartographie Google + Maptimize, …
La dernière semaine a été uniquement consacrée à du debuggage et pour ça j’ai mis un peu plus mon nez dans le code source du site et donc dans la partie “vue” (le V de MVC).

Je ne peux surtout pas prétendre connaître Symfony dans ce qu’il a de particulier par rapport à d’autres framework web (et MVC en particulier), mais je peux comparer ce que j’ai vu et ce que l’équipe raconte au quotidien avec ce que je connais et vis au quotidien depuis 3 ans avec Ruby et Rails.

De plus, j’ai développé quasi-exclusivement en PHP depuis les premiers temps du PHP3 jusqu’à PHP5, donc même si j’ai passablement oublié certains réflexes de manipulation du langage et la plupart de noms de méthodes, je pense avoir un avis assez circonstancié sur PHP.

La question

Pour le développement de la partie visible du projet sur lequel je suis mobilisé, d’autres personnes de l’équipe vont participer activement et durablement. Une question se pose donc inévitablement : Ruby on Rails ou bien Symfony ?

Notre boss comprend bien quand on lui parle de technique, avec des arguments clairs, mais il ne se sent pas (à raison) en mesure de décider lui-même d’un framework ou d’un langage plutôt qu’un autre. Il nous a donc demandé de préparer une discussion sur cette question, en apportant surtout des faits et des remarques objectives afin de tout mettre sur la table et tenter en équipe de prendre la bonne décision.

Je suis convaincu qu’il ne s’agit pas de valider ou invalider les choix des uns et des autres, mais plutôt de faire un état des lieux et s’orienter dans la meilleure décision.

Comme je suis quelqu’un de passionné, et qui ne se lance dans les choses qu’avec une forte conviction, j’ai quand même envie de convaincre que mon choix de quitter le développement en PHP pour le faire en Ruby n’est pas juste “mon choix” mais un choix lucide et cohérent.

Alors j’ai sorti un bout de papier et un crayon (ou plutôt un document “untitled.txt” et mon beau clavier) pour pondre une liste d’arguments.

Et puis je me suis dit que garder tout ça pour nous, en interne, était un peu égoïste. Pourquoi ne pas partager mes observations et mon analyse. Je ne pense pas que quiconque (au delà de notre équipe et mes copains geeks) s’intéresse à mon avis sur la question, mais un avis, ça peut donner des idées, participer à une réflexion, …

Présentation factuelle de Ruby et Rails

Ici je ne présente que des points clés, du moins ceux auxquels j’ai pensé.
Je ne détaillerai pas ces points, d’autres l’ont fait bien mieux que moi.

Ruby

• 100% objet, pas de primitives
• langage concis et lisible : moins de code, moins de bugs
• langage dynamique, fortement typé
• imprégné des méthodes de tests TDD et BDD (nombreux frameworks disponibles)
• synergie avec les méthodes agiles
• Ruby en ligne de commande (IRB), pratique pour des essais, …
• Rubygems : gestionnaire de paquets additionnels
• vitesse d’apprentissage
• syntaxe et idiomes riches et avancés
• meta-programmation
• inspiré des meilleurs langages reconnus : Smalltalk, Lisp, Python, Perl, …
• forte implication et marques de confiance des ténors : IBM, Sun, Apple, Microsoft, SAP, …
• de nombreux frameworks de premier plan : Rails, Sinatra, …

J’invite à la lecture de la page de Ruby sur Wikipedia, que je trouve assez complète et claire.

Rails

• dédié au développement d’appli web
• architecture MVC
• naturellement REST
• forte incitation à DRY
• convention plutôt que configuration
• grand variété de helpers
• des outils annexes très utiles : débuggage, déploiement, monitoring, …
• des environnements d’exécution bien définis et cloisonnés
• WebServices-friendly
• système strict de migration des bases de données
• framework complet accessible en ligne de commande
• variété de backend pour le cache et les sessions : mémoire, fichiers, BDD, memcached, …
• I18n
• communauté très active
• documentation riche (en ligne, livres, …)
• Rack middlewares => empilement de briques fonctionnelles dédiées et modulaires : cache, debug, auth, …
• logging avancé et personnalisable
• fortes opinions, mais autres choix possibles : ORM, templates, framework JS, …

Pour une introduction à Rails, je vous renvoie vers le le guide de démarrage pour Rails ou Rails in a Nutshell (qui est encore en beta).

Analyse subjective (mais convaincue) de Ruby & Rails vs. PHP & Symfony

Là, je sors un peu des faits indéniables pour m’aventurer dans ma propre analyse des différences entre ces 2 frameworks (et leur langage sous-jacent respectif). Cette analyse est forcément subjective et je serai ravi d’entendre des avis contraires ou complémentaires.

PHP vs. Ruby

Prenons la métaphore de la caisse à outils.

PHP est une énorme caisse, dans laquelle il y a des outils pour presque tout, tellement que ça devient difficile de tout connaître. Il n’y a qu’à voir le site de la documentation officielle où le nombre de méthodes est impressionnant, sans parler de celles des librairies standards.

Il y a souvent plusieurs outils ou variantes pour faire presque la même chose. C’est pas forcément facile de savoir lequel choisir.

Cette boîte grandi très vite, il y a régulièrement de nouveaux outils, d’autres évoluent et certains disparaissent.

Ruby est une caisse beaucoup plus modeste, qui permet de faire tout autant de chose, mais il y a très peu de doublons ou recoupements.

Les outils sont robustes, stables et surtout cohérents entre eux. Le contenu de la boîte évolue peu, rarement et uniquement en cas de forte nécessité. Même entre les versions majeures (1.8 et 1.9) il y a très forte compatibilité. Au sein de la branche 1.8 il n’y a eu presqu’aucune perte de compatibilité importante depuis plus de 3 ans (sortie de la 1.8.5 en août 2006).

Les mises à jour de Ruby, en tant que langage, sont rares (12 à 18 mois entre chaque version stable) car il n’y a pas ou extrêmement peu de bugs, elles ne concernent que des nouveautés ou améliorations de fond. La raison de ce très faible nombre de bugs et failles de sécurité sont simples : le code est soumis à des tests systématiques et poussés (c’est dans la culture de la communauté Ruby) et le code étant simple lisible et clair, il est facile de l’auditer et le comprendre et donc d’en débusquer les failles.

À l’inverse, PHP est mis à jour beaucoup plus souvent (plusieurs fois par an) et contient de nombreux correctifs de bugs en plus de nouvelles fonctionnalités. Il est reconnu que les failles de sécurité importantes ou critiques sont relativement fréquentes.

La raison d’être de PHP n’était pas d’apporter une approche nouvelle du développement mais de répondre à un besoin simple et bien identifié : traiter les données issues d’un formulaire web. La simplicité et les fonctionnalités de ce nouveau langage l’ont rendu rapidement populaire chez les développeurs web car il n’y avait plus besoin de faire des CGI en Perl pour rendre des sites dynamiques.

Face à ce gain de popularité, le langage a grandi et permis de faire de plus en plus de choses assez facilement, mais rapidement on a constaté le manque de fondations solides, en particulier sur l’aspect Objet.

PHP rivalise alors, en terme de popularité et d’audience, avec Perl, Java, … et cherche alors à combler les manques et répondre aux critiques. Le résultat est plutôt efficace, mais les outils du début restent là et les mauvaises pratiques qui vont avec aussi.

Au final on a un langage riche, mais brouillon, fourre-tout, qui évolue par stratification et pas par transformation. Les fondations manquent de rigueur et de profondeur.

Ruby est un langage qui a été conçu avec une approche plus scientifique et globale. Son créateur voulait un langage moderne, plus proche des attentes de l’humain que de celles de la machine, mais qui reconnaisse et embrasse l’état de l’art, ce qui s’est fait de mieux. Il s’est donc contenté (si on peut dire) d’appliquer la parole des vieux sages dans un contexte moderne.

Ruby adopte le principe de la moindre surprise (au sens de la cohérence maximale) selon lequel le langage doit se comporter de manière à minimiser la confusion. Lorsqu’on découvre Ruby, qu’on vienne de Java, PHP ou Python, on est forcément surpris par la syntaxe, les idiomes, … mais avec le temps on adopte la “manière Ruby” et plus rien n’étonne. Dans d’autres langages, même après plusieurs années d’utilisation, on est parfois étonné ou dérouté par certains fonctionnements.

La syntaxe du langage est au service de son utilisateur, en favorisant la lisibilité et la concision. La simplicité des outils de base permet d’apprendre vite et de savoir rapidement lequel utiliser.

Ruby est bâti sur des fondations robustes et très strictes ; celles du tout Objet (il n’y a pas de primitives), de la meta-programmation, du typage dynamique mais fort, …

Symfony vs. Rails

Ruby on Rails est issu du développement d’une application web (Basecamp). Son créateur voulait se lancer dans le développement web et a cherché le langage avec lequel il se sentait le plus à l’aise et il s’est arrêté sur Ruby. Il a ensuite échafaudé un framework dédié au web en tirant réellement parti de ce que permet Ruby.

La démarche partait d’un objectif/besoin connu, il fallait trouver l’outil adapté pour l’atteindre.

Rails ne serait pas ce qu’il est sans Ruby. On ne peut pas recréer Rails sur un autre langage sans faire des tours de passe-passe et en perdre l’essence.

Symfony est issu du manque de bon framework web en PHP. Son créateur a voulu reprendre les bonnes idées d’autres frameworks (surtout Rails) sur d’autres langages pour les adapter sur PHP.

La démarche semble différente et partir d’un langage connu sur lequel construire en s’inspirant de références.

Pour ce que j’ai pu en voir et pour que Symfony ait le succès qu’il a, son développeur principal et la communauté qu’il a agrégée ont forcément accompli quelque chose de remarquable.

Pour autant, j’ai le sentiment que le plus grand handicap de Symfony, c’est PHP.

Conclusion

Au final, on sent que j’ai les idées bien arrêtées. J’espère ne pas avoir faire preuve de mauvaise foi ni avoir dit trop de bêtises.

Il m’arrive de dire que telle techno ou tel produit sont nuls. Mais pour le cas de PHP (et donc de Symfony), je ne dis pas que c’est nul et bon aux orties, au contraire.

Je dois certainement mon parcours de développeur web à PHP et à ce que j’ai pu faire avec. J’ai juste l’intime conviction d’avoir trouvé une évolution, une suite, qui me permet d’aller plus vite, plus loin, avec plus de plaisir/passion.

C’est un peu comme de passer de CVS ou Subversion à Git ou Mercurial. Vu de loin c’est la même chose, mais de près, ce sont 2 générations d’outils sui marquent un véritable progrès.

 

---

 

Mise à jour 1 : Au terme d’une longue réunion d’équipe, nous avons choisi une approche à 2 têtes. Le premier projet (Chambres à Part) reste évidemment développé avec Symfony (donc en PHP) mais le second sera entièrement développé avec Ruby on Rails.

Évidemment, je pense que c’est le bon choix. Pour moi, c’est surtout le bon choix technologique, pour toutes les raisons que j’ai déjà développées plus haut.

Du point de vue de la stratégie d’entreprise, je trouve que la prise de risque est modérée et ça va nous mettre dans une situation de réelle fusion et enrichissement des compétences.

Pendant les prochains mois, ceux parmi nous qui “viennent de Symfony” vont devoir apprendre de nouvelles choses en mettant à profit leurs années d’expérience en développement et particulièrement avec un framework MVC, … Le challenge sera de tirer le plus profit de cette expérience proche tout en “embrassant” les particularités de Ruby et de Rails.

Quelque part, ça va me mettre en situation de formateur, ce qui est très excitant mais aussi une responsabilité forte. Mais comme je suis absolument passionné par ce que je fais et connais, je vais me régaler dans cette partie de mon boulot.

Par ailleurs, cette juxtaposition d’outils va me permettre de voir plus en détail l’univers de Symfony et les évolutions de PHP (depuis que je l’ai laissé de côté). Même si je ne vois pas mon avenir de ce côté là, ça me forcera à être un peu moins monocorde.

Enfin bon, je suis bien content que la balance ait penché, non pas de mon côté (ça serait une marque d’égo) mais du côté que j’ai choisi.

Mise à jour 2 : Vous trouverez sur le site de Ruby une courte liste des similitudes et différences à quoi s’attendre en passant de PHP à Ruby.