M'enfin ?!?

Rails et la sécurité

M'enfin ?!? — Fri, 18 Jul 2008 23:45:00 +0200

Introduction

La sécurité des applications web est souvent un sujet délicat : peu de temps à y consacrer, mais cela peut avoir des conséquences assez graves. Pas de panique ! Ruby on Rails est bien armé et avec un peu de rigueur, on peut se protéger sans trop de difficultés. Nous allons voir les principaux types d'attaques et comment les éviter.

Injections SQL

Commençons par un grand classique : les injections SQL. Une injection SQL consiste simplement à envoyer des données non prévues dans une requête SQL. Prenons comme exemple une application web où les utilisateurs sont authentifiés de la manière suivante :

@current_user = User.find(:first, :conditions => "login='#{params[:login]}' AND password='#{params[:password]}'")

En temps normal, quand Joe s'authentifie, la requête SQL suivante est exécutée :

SELECT * FROM users WHERE login='Joe' AND password='0521bc575b0ff61daa62494c7ae9c5b6' LIMIT 1;

Mais supposons maintenant que Kevin, un Script Kiddie, passe dans le coin et décide de mettre "Joe'; --" dans le champ login. La requête SQL va alors ressembler à :

SELECT * FROM users WHERE login='Joe'; --' AND password='00000000000000000000000000000000' LIMIT 1;

Kevin a réussi à se faire passer pour Joe sans connaître son mot de passe !

Heureusement, Active Record permet de nous en protéger assez facilement. Pour cela, il suffit d'utiliser les formes échappées comme cela :

@current_user = User.find(:first, :conditions => ["login=? AND password=?", params[:login], params[:password]])

ou de façon équivalente :

@current_user = User.find(:first, :conditions => {:login => params[:login], :password => params[:password]})

Dans les 2 cas, Active Record rajoutera un caractère '\' devant chaque apostrophe de façon à éviter les injections SQL.

L'authentification et la gestion des droits

Pour la grande majorité des projets, l'authentification (et la gestion des droits qui vont avec) est un passage obligé. Pour cela, il existe un certain nombre de points importants à respecter comme le chiffrement des mots de passe stockés en base de données (ce que nous n'avons pas fait dans l'exemple précédent). Les erreurs sont vite arrivées, aussi je vous recommande d'utiliser des plugins reconnus comme Restful Authentication, OpenID Authentication et Authorization.

Il ne vous reste plus qu'à faire attention à un dernier détail : mettre en cache des pages nécessitant une authentification est une mauvaise idée. En effet, ces pages vont alors être servies par le serveur web sans passer Rails, et donc sans vérification de l'authentification.

Se protéger des données forgées

L'étape suivante consiste à bien sécuriser l'accès aux données, aussi bien en lecture qu'en écriture. En effet, Rails possède quelques raccourcis très pratiques, mais qui peuvent poser problème quand ils sont mal maîtrisés. Le plus courant est l'affectation de masse, technique qui consiste à créer un objet Active Record directement depuis les paramètres de la requête HTTP. Par exemple, la création d'un compte utilisateur pourra s'effectuer de la façon suivante :

@user = User.create(params[:user])

Supposons maintenant que la table 'users' comporte un champ 'admin' qui vaut 0 par défaut ou 1 pour les super-utilisateurs. Un utilisateur malveillant pourrait forger la requête HTTP pour ajouter un paramètre useradmin=1 afin de gagner les pouvoirs réservés aux admins. La première solution pour se protéger de cette attaque consiste à écrire explicitement quels sont les paramètres autorisés :

@user = User.create(
        :login => params[:user][:login],
        :email => params[:user][:email],
        :password => params[:user][:password],
        :cgu => params[:user][:cgu])

Mais ceci peut vite devenir pénible quand on commence à avoir des formulaires un peu conséquents. C'est pourquoi on lui préfère généralement la deuxième solution : la déclaration dans le modèle de la liste des attributs qui ne peuvent pas être modifiés. Cette déclaration se fait à l'aide de la méthode attr_protected comme suit :

class User < ActiveRecord::Base
        attr_protected :admin
        ...
end

Nous pouvons de nouveau utiliser l'affectation de masse sans craindre qu'un utilisateur se fasse passer pour un admin, Rails s'occupe de filtrer les paramètres.

Dans le même style, un attaquant peut essayer de forger des URL. Si, par exemple, l'utilisateur authentifié peut supprimer l'item n°123 qui lui appartient, en appelant l'URL /items/delete/123, alors que se passera-t-il s'il appelle la même URL pour l'item n°456 qui ne lui appartient pas ? La réponse dépend du code de la méthode delete. Une implémentation de base pourrait ressembler à :

class ItemsController < ApplicationController
        def delete
                Item.delete(params[:id])
        end
end

Pour se protéger des URL forgées, on pourrait la transformer en :

class ItemsController < ApplicationController
        def delete
                @item = @current_user.items.find(params[:id])
                @item.delete if @item
        end
end

Ce n'est pas parfait (on pourrait vérifier que c'est bien une requête de type POST), mais c'est déjà beaucoup mieux.

Un dernier petit truc pour la route avant de passer à autre chose. Si vous avez une API pour laquelle vous utilisez la sérialisation XML, il peut être intéressant de surcharger ActiveRecord#to_xml pour que le champ secret_field n'y apparaisse pas :

class Item < ActiveRecord::Base
        def to_xml(args={})
                super({:except => [:secret_field]}.merge(args))
        end
end

Cross-Site Scripting

Jusque maintenant, nous avons vu des attaques directes : un utilisateur essaye de s'en prendre à notre site. Il existe également des attaques plus pernicieuses que l'on classe sous le nom de Cross-Site Scripting (XSS en abrégé). Leur but est de s'en prendre aux utilisateurs de notre site en glissant des cochonneries sur notre site. Ceci peut aller du spammeur qui mettra une balise <iframe> vers son site dans tous les formulaires qui lui passent sous la main à l'injection de javascript non maîtrisé.

Par exemple, quelqu'un crée un item dont la description est la suivante :

<script>document.location='http://www.programmez.com/';</script>

Si maintenant un visiteur affiche la description de cet item, il sera redirigé vers le site www.programmez.com. Vous vous dites que c'est ennuyeux mais pas bien méchant ? Oui, mais la même technique permet de voler les cookies et donc les sessions associées. Nous allons donc chercher à nous protéger de ces failles XSS.

Pour cela, il est important de faire une distinction entre 2 cas : est-ce que le champ que vous allez afficher peut contenir des balises HTML ou non ? Pour afficher le nom d'un item, on sera dans le premier cas, à savoir pas de balises HTML : on veut juste afficher le nom tel que l'a rentré son propriétaire. Par contre, on peut souhaiter être plus souple pour la description de l'item et laisser la possibilité d'avoir un titre (balise <h1>), du gras (<b>) ou de l'italique (<i>). Ces 2 cas ne se traitent pas de la même façon. Pour le premier cas, Rails nous offre un moyen simple de nous en protéger : le helper h. En pratique, à chaque fois que l'on souhaitera afficher le titre d'un item, on procédera de la manière suivante :

<%=h @item.title %>

Ce h va convertir les caractères qui pourraient être interprétés par un navigateur web en l'entité HTML correspondante. Problème résolu.

Le deuxième cas est par contre plus difficile à traiter. Vous pouvez être tenté d'utiliser un moteur de formatage de texte comme RedCloth. Attention, cela ne suffit pas à filtrer toutes les attaques ! Pour votre tranquillité, il vaut mieux utiliser le plugin WhiteList. Depuis Rails 2.0, ce plugin fait partie du framework et peut s'utiliser de la façon suivante :

<%= sanitize @item.description, :tags => %w(b i h1) %>

Il est possible de déclarer les balises autorisées de manière globale : je vous renvoie à la documentation officielle. Et pour ceux qui veulent être sûrs de ne pas oublier d'appel à h ou à sanitize, il existe des moteurs de template alternatifs comme Safe ERB ou Erubis. Ces moteurs adoptent l'approche opposée : ils filtrent par défaut tous les éléments <%= %>, charge au développeur d'indiquer explicitement ceux pour lequel le moteur ne fera pas de filtrage.

Cross-Site Request Forgeries

Juste avant de finir, je voudrais juste dire un mot sur un dernier type d'attaques. Les CSRF, abréviation de Cross-Site Request Forgery, sont des attaques complexes qui visent à forcer l'utilisateur à envoyer une requête HTTP vers notre site lorsque celui-ci visitera le site de l'attaquant. Je vous renvoie à wikipedia si vous voulez comprendre comment fonctionne ce type d'attaques. Sachez que Rails vous protège de celles-ci depuis la version 2.0 et qu'il existe un plugin pour les versions plus anciennes : CSRF-killer.

Conclusion

Nous avons pu voir qu'en prenant quelques bonnes habitudes, on pouvait développer des applications sûres en Rails. Il reste cependant des sujets que je n'ai pas abordés comme l'administration de Rails, apache ou MySQL (suite), la manipulation des fichiers ou encore le filtrage des informations sensibles dans les logs. Il est également important de se tenir au courant des mises à jour de sécurité de Rails et des plugins que vous utilisez.

Je remercie Benoît Sibaud pour sa relecture attentive.

Références

LinuxFR.org a dix ans, soirée Firefox 3 et autres joyeusetés

M'enfin ?!? — Sat, 28 Jun 2008 18:00:00 +0200

Je n'ai pas pour habitude de faire des billets en vrac, mais ce sera exceptionnellement le cas. Je souhaite en effet vous parler de plusieurs points qui n'attendront pas :

LinuxFR a 10 ans !

Hé oui, c'est aujourd'hui, le 28 juin, que LinuxFR fête 10 ans de dépêches, journaux et autres informations autour de Linux et des Logiciels Libres. J'espère que LinuxFR pourra continuer à animer la vie de la communauté du Logiciel Libre pour encore quelques années.

Soirée Firefox 3

Hier soir avait lieu la soirée Firefox 3. Je dois avouer que j'ai été déçu par la soirée : peu de monde, pas de musique, l'ambiance n'était pas au rendez-vous :/ Tristan Nitot a pris des photos de la soirée.

RMLL du 1er au 5 juillet

La semaine prochaine, ce sera RMLL. Ca se passe à Mont-de-Marsan, et j'y serais pour tenir le stand de Ruby France et donner une conférence sur LinuxFR. J'espère y croiser des lecteurs de mon blog ;)

Un gros merci à AF83 qui me laisse y aller pendant mes jours de boulot.

Do You Buzz

Do You Buzz est un nouveau service en ligne pour publier son CV. Chose intéressante, c'est le premier site développé avec le framework Turbulences en dehors d'AF83.

Le site est encore en bêta privée, mais il marche déjà très bien et l'interface est vraiment agréable à utiliser. J'en sais quelque chose, car je fais parti des premiers beta-testeurs (mon CV est visible sur http://www.doyoubuzz.com/bruno-mich...).

Github theme for Vim

M'enfin ?!? — Fri, 30 May 2008 02:14:00 +0200

Scott Becker has made a Github theme for Textmate, so I've decided to made a Github theme for ViM.

It's available on github: Github Vim Theme.

Outils pour tracer des graphes

M'enfin ?!? — Sat, 10 May 2008 01:30:00 +0200

Je cherche depuis un certain temps un outil pour tracer des graphes. En général, j'utilise la suite Graphviz pour faire cela. Le principe est relativement simple : on décrit le graphe dans un fichier au format dot, puis on utilise un des 5 outils (dot, neato, fdp, circo et twopi) pour générer une image. Cela marche plutôt bien, mais les graphes générés sont sobres, pour ne pas dire moches (voir la galerie).

Je connaissais également LGL, mais il est surtout adapté pour tracer des graphes avec beaucoup de noeuds et/ou arêtes. Il existe aussi des outils pour tracer des diagrammes (genre Dia) qui peuvent être utilisés pour tracer des graphes, mais je préfère de loin l'approche de graphviz.

Et récemment, je suis tombé sur Nodebox : le choc, des jolis graphes ! Malheureusement, Nodebox fonctionne sous MacOSX. Il existe bien un port pour GNU/Linux sous QT, mais je n'arrive pas à utiliser le module Graph avec celui-ci :/ Shoebox est une réécriture de nodebox (sous Cairo ce coup-ci), mais j'ai l'impression qu'il n'est pas encore assez avancé pour faire quelque chose d'utile avec.

Toujours à partir de Nodebox, j'ai découvert NetworkX, mais, si j'ai bien compris, c'est une surcouche à Graphviz. Les exemples de la gallerie me semblent quand même plus jolis que ceux de GraphViz. Est-ce que l'auteur de NetworkX a passé du temps pour faire ces exemples ou est-ce que je me suis trompé sur NetworkX ? Je ne saurais dire, mais cela vaudrait sûrement le coup que j'y rejette un coup d'oeil à l'occasion.

Enfin, la solution viendra peut être du Javascript. Le JavaScript Information Visualization Toolkit (JIT) est une bibliothèque pour tracer des graphes. Ce n'est pas aussi simple que GraphViz et, pour le moment, limité aux arbres, mais cela pourrait devenir une solution intéressante. Le projet Processing.js montre que l'on peut utiliser la balise Canvas pour faire un rendu qui n'a rien à envier au Desktop. Alors qui sait, peut être que JIT pourra vraiment devenir la solution pour tracer de jolis graphes même si l'utilisation de javascript peut surprendre pour cela...

Mise à jour : je viens de découvrir un nouveau venu : Ubigraph. Les démos sont impressionnantes, mais le serveur n'est malheureusement pas sous une licence libre.

Annonces RailsConf 2008

M'enfin ?!? — Thu, 08 May 2008 17:37:00 +0200

La RailsConf 2008, la grande messe annuelle des railers, aura lieu du 29 mai au 6 juin. A cette occasion, un certain nombre d'annonces devrait être faites. Bien entendu, la plus attendue sera celle de Ruby on Rails 2.1. Mais c'est loin d'être la seule. Coté framework, on devrait également entendre parler de Merb dont la version 1.0 devrait être annoncée par ce RailsConf si tout va bien.

On attend également beaucoup de choses pour les interpréteurs Ruby : arrivée du tout nouveau MagLev, Rubinius faisant tourner des applis Rails, JRuby plus rapide que l'interpréteur Ruby officiel pour les applis Rails ? Pour le moment, ce ne sont que des objectifs (ou au mieux des rumeurs), mais on sent une certaine agitation de ce coté-là.

Enfin, la mode est au moteur de réseaux sociaux, et le RailsConf sera l'endroit pour en parler, mais ceci fera l'objet d'un autre post sur ce blog ;-) Bref, plein de bonnes choses en vue qui me feront regretter de ne pas pouvoir y aller...

Dossier Ruby on Rails dans programmez

M'enfin ?!? — Wed, 02 Apr 2008 01:23:00 +0200

La revue Programmez sort un dossier sur Ruby on Rails. La première partie de ce dossier est sortie ce mois-ci, et la suite sera pour le mois prochain. Si je vous parle de cela, c'est parce que j'ai l'honneur de participer à ce dossier : j'ai écrit le dossier sur Rails et la sécurité. Vous n'aurez plus d'excuses pour ne pas suivre les règles de bases pour s'assurer de la sécurité de son appli rails.

Mise à jour : l'article en question est maintenant disponible sur http://blog.menfin.info/post/2008/0....

Afficher la branche Git courante dans le prompt de ZSH

M'enfin ?!? — Sat, 15 Mar 2008 20:12:00 +0100

Je suis tombé sur un tips bien sympa : Show Your GIT Branch Name In Your Prompt. Il y est expliqué comment avoir la branche Git en cours dans son prompt avec Bash.

J'ai adapaté ca pour zsh. Voici un extrait de mon zshrc :

export PS1='%~ $(git_branch)%# '

function git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1) /'
}

setopt PROMPT_SUBST

La seule difficulté fût de se rendre compte qu'il fallait activer une option pour que ca marche, et de savoir quelle était cette option (PROMPT_SUBST en l'occurence).

Ainsi que je suis sous un répertoire normal, j'ai un prompt de la forme ~/Desktop % , et quand je suis dans un répertoire versionné sous Git, ca donne : ~/mon_projet (ma_branche) % . Ce n'est pas grand chose, mais comme il paraît que c'est une bonne pratique de faire des branches sous Git, autant avoir en permance le nom de la branche courante sous les yeux.

PS : j'ai des invitations pour GitHub si ca intéresse des gens.

4ème apéro Ruby

M'enfin ?!? — Sun, 17 Feb 2008 15:53:00 +0100

L'association Ruby France organise pour la quatrième fois un apéro Ruby à la cantine. Ce sera l'occasion de discuter autour d'un verre de Ruby et de découvrir la cantine. Il devrait notamment y avoir une présentation de Ruby 1.9 et des lightning talks.

J'y serais et vous ?

Mise à jour : j'ai oublié le lien vers l'annonce officielle.

Portrait of a N00b

M'enfin ?!? — Tue, 12 Feb 2008 01:02:00 +0100

Steve Yegge, un blogger influent qui travaille chez Google, a posté un article intitulé « Portrait of a N00b ». Comme à son habitude, c'est un très long post où il explique les différences dans la manière de coder (et commenter son code) entre un développeur peu expérimenté et un développeur avec 20 ans d'expérience.

S'en suit une digression très intéressante entre langages à typage statique (Ocaml, Haskell), langages à typage dynamique (Perl, Python, Ruby), et les langages classiques (C++, Java) à typage statique mais qui vous laisse tricher avec les types. On y trouve quelques perles :

If static types are comments, then I think we can conclude that people who rely too much on static types, people who really love the static modeling process, are n00bs.

You can write C++ like straight C code if you like, using buffers and pointers and nary a user-defined type to be found. Or you can spend weeks agonizing over template metaprogramming with your peers, trying to force the type system to do something it's just not powerful enough to express.

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done.

Mais le plus simple reste d'aller lire l'original : Portrait of a N00b. C'est long, mais ca en vaut largement la lecture. Et si vous avez encore du temps, les autres articles sont aussi des lectures recommandées.

Ai-je précisé que je me retrouve plus dans la peau du dév expérimenté que du N00b, même si c'est un prétentieux, vu que je suis encore vraiment loin d'avoir 20 ans d'expérience ?

Nouveaux tips pour vim

M'enfin ?!? — Tue, 22 Jan 2008 01:23:00 +0100

Voici une nouvelle fournée de tips pour Vim. Pour les retardataires, la première série est toujours disponible par là.

CTRL+v reste une valeur sûre : ca active la sélection rectangulaire. Suivie de I, ca permet d'insérer un même texte sur plusieurs lignes. Au contraire, avec x, on peut supprimer une colonne.
:Man permet d'afficher une page de man directement dans Vim (avec la coloration syntaxique) ;
j'ai rajouté la ligne suivante dans mon vimrc pour pouvoir insérer facilement des Lorem ipsum :

iab lorem Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Sed non risus. Suspendisse lectus tortor, dignissim sit amet, adipiscing nec, ultricies sed, dolor. Cras elementum ultrices diam. Maecenas ligula massa, varius a, semper congue, euismod non, mi. Proin porttitor, orci nec nonummy molestie, enim est eleifend mi, non fermentum diam nisl sit amet erat. Duis semper. Duis arcu massa, scelerisque vitae, consequat in, pretium a, enim. Pellentesque congue. Ut in risus volutpat libero pharetra tempor. Cras vestibulum bibendum augue. Praesent egestas leo in pede. Praesent blandit odio eu enim. Pellentesque sed dui ut augue blandit sodales. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Aliquam nibh. Mauris ac mauris sed pede pellentesque fermentum. Maecenas adipiscing ante non diam sodales hendrerit.

Voilà, c'est tout pour aujourd'hui.

J'y serai

M'enfin ?!? — Tue, 04 Dec 2007 00:31:00 +0100

Mercurial sur mon MyBook

M'enfin ?!? — Sat, 01 Dec 2007 23:10:00 +0100

J'ai installé mercurial sur mon MyBook. Ce n'est pas très compliqué, mais voici quand même la méthode que j'ai utilisée pour ceux qui n'ont pas envie de chercher. La première chose à faire, c'est se connecter en ssh (si sshd n'est activé, vous pouvez le faire grâce à la méthode de Martin Hinner). Ensuite, comme mercurial est en Python, il faut installer Python :

$ cd /tmp
$ wget http://www.python.org/ftp/python/2.5.1/Python-2.5.1.tar.bz2
$ tar xvjf Python-2.5.1.tar.bz2
$ cd Python-2.5.1
$ ./configure --disable-ipv6 --disable-shared --with-cxx=no --with-threads
$ make
$ sudo make install

Puis, on peut passer à l'install de mercurial proprement dit :

$ cd /tmp
$ wget http://www.selenic.com/mercurial/release/mercurial-0.9.5.tar.gz
$ tar xvzf mercurial-0.9.5.tar.gz
$ cd mercurial-0.9.5
$ make
$ sudo make install-bin

Un petit hg -v pour tester, et c'est déjà fini.

IRB, un outil à (re)découvrir

M'enfin ?!? — Sat, 01 Dec 2007 00:33:00 +0100

IRB est un outil génial pour tester rapidement un truc en Ruby. C'est une sorte d'interpréteur Ruby qui fonctionne comme un shell : vous tapez une ligne de Ruby, irb l'interprête et vous donne le résultat, vous tapez une autre ligne, irb l'interprête en tenant compte de la première ligne, et ainsi de suite. Voici par exemple ce que cela donne (avec en gras, ce que j'ai tapé) :

>> titi = 2 + 3

> 5

>> toto = titi * 4

> 20

Pour ceux qui veulent en savoir plus, je recommande de lire le chapitre consacré à IRB dans Le Guide (Poignant) de Why's vers Ruby et d'essayer ca dans Try Ruby qui est, en gros, un IRB dans votre navigateur web. Il est possible de configurer IRB via le fichier $HOME/.irbrc : changer le prompt, charger des fichiers, activer l'auto-complétion, etc. Comme d'autres personnes l'ont fait avant moi, je poste mon fichier de conf .irbrc pour que chacun puisse s'en inspirer (et aussi pour le retrouver plus facilement quand je ne suis pas chez moi ;-)

  require "yaml"

  require "irb/completion"

  

  IRB.conf[:USE_REALINE] = true

  IRB.conf[:PROMPT_MODE] = :SIMPLE

  

  # History with readline

  HISTFILE = "~/.irb.hist"

  MAXHISTSIZE = 100

  

  # what? (gem install what_methods)

  require "what_methods"

  

  # Wirble (gem install wirble)

  require "wirble"

  Wirble.init

  Wirble.colorize

  

  # Just for Rails...

  if ENV["RAILS_ENV"]

    IRB.conf[:IRB_RC] = Proc.new do

      ActiveRecord::Base.logger = Logger.new(STDOUT)

      ActiveRecord::Base.instance_eval { alias :[] :find }

    end

  end

Nouveau disque dur : MyBook World Edition

M'enfin ?!? — Mon, 26 Nov 2007 01:42:00 +0100

Je viens de m'acheter un disque dur externe Western Digital MyBook World Edition. La bête doit principalement me servir pour mes sauvegardes, mais avec ses 500 Go, je devrais avoir de la place pour d'autres choses. J'ai choisi ce modèle car je voulais un disque dur branché sur de l'ethernet, pas en usb, et qu'en plus j'avais lu sur http://jeromeandrieux.blogspot.com/... qu'il avait le bon goût de tourner sous linux (les sources du firmware sous licence GPL sont disponibles sur http://support.wdc.com/download/ind...).

Ce que j'ai déjà fait

le brancher
aller sur l'interface web : http://admin:123456@<l'adresse IP du Mybook>
rajouter un utilisateur sur cette interface
activer l'accès ssh grâce à la méthode de Martin Hinner
se logger en ssh dessus avec l'utilisateur créé précédement
désactiver mionet toujours grâce à http://martin.hinner.info/mybook/disable_mionet.php
faire joujou avec l'interface web
et finalement commencer mes sauvegardes à la main (à coups de scp)

Ce qu'il reste à faire

Visiblement, il est possible de faire des choses bien sympathiques comme installer http://vsftpd.beasts.org/ (un serveur FTP bien secure), http://samba.anu.edu.au/rsync/ ou encore http://php.net (en réutilisant le lighttpd de l'interface web) dessus :

Il est également possible de mettre en veille le disque dur d'après http://kyyhkynen.net/stuff/mybook/.

Tips pour Vim

M'enfin ?!? — Sun, 18 Nov 2007 02:10:00 +0100

Voici quelques trucs pour ViM que j'ai utilisé aujourd'hui :

mettre au BufRead,BufNewFile /etc/apache/** setf apache2 dans le fichier $HOME/.vim/ftdetect/apache.vim pour que les fichiers /etc/apache2 soient bien reconnus comme des fichiers de conf d'apache (pour la coloration syntaxique) ;
% pour sauter d'une parenthèse ouvrante à la parenthèse fermante qui lui correspond (et vice-versa) : c'est un déplacement classique dans ViM, mais ca fait toujours plaisir quand on a des dizaines de parenthèses qui s'ouvrent et se ferment dans tous les sens ;
248| permet de se déplacer au 248ème caractère de la ligne courante ;
gg247<barre d'esspacement> permet de se déplacer au 248ème caractère du fichier (en fait, ca permet de se placer sur le premier caractère, puis d'avancer 247 fois d'un caractère).

Bref, rien d'extraordinaire, mais je suis bien malheureux quand je me retrouve sous un autre éditeur et que je ne peux plus utiliser ces petits trucs.

Ce qui me manque sous Mac OSX

M'enfin ?!? — Tue, 23 Oct 2007 00:34:00 +0200

J'utilise GNU/Linux depuis plusieurs années, mais depuis quelques mois, je suis sous Mac OSX au boulot. Dans l'ensemble, je dois avouer que c'est très joli et facile à utiliser. Mais sur certains points, j'ai trouvé Mac OSX très mal foutu par rapport à ce que l'on peut trouver sous GNU/Linux. Voici une petite liste des trucs qui m'ont le plus géné (et qui me gênent encore) :

#1 - Le clavier

Le clavier de mon mac m'a longtemps dérouté, et encore maintenant, je ne sais pas comment se nomme toutes les touches. Et faire certains caractères est mission impossible si personne ne vous aide la première fois : faut savoir que pour faire un pipe |, il faut une combinaison de 3 touches dont la lettre l. C'est pas marqué sur le clavier, et c'est vraiment pas intuitif.

#2 - L'absence de bureaux virtuels

Par défaut, il n'y a pas de bureaux virtuels sous Mac OSX. Il parait qu'on peut installer des softwares pour faire ca, mais je n'ai pas essayé. Est-ce qu'Apple aurait peur d'être poursuivi à cause du brevet sur les bureaux virtuels ^[1] ?

#3 - Le Window Manager sous évolué

Je ne comprends pas que le Window Manager soit aussi peu évolué. J'ai peut-être été habitué à des Window Manager très perfectionnés sous GNU/Linux, mais le choc a été dur : je n'ai pas trouvé comment garder une fenêtre au premier plan, comment avoir l'auto-focus, etc. Je ne sais pas pour vous, mais pour moi, ce sont vraiment des fonctions de base.

#4 - La barre de menu

Mais quelle idée d'aller mettre la barre de menu à cet endroit ? Je travaille sur un portable avec un deuxième écran. Pas de chance, la barre de menu ne s'affiche que en haut de l'écran du portable, et pas du tout sur mon écran LCD 20". Mon curseur de souris fait des kilomètres à cause de ce menu mal placé.

#5 - Le copier-coller

Tout le reste, je pense que je peux survivre avec, mais le copier-coller, c'est vraiment le truc qui me mine la vie. Explications : sous GNU/Linux, il suffit de sélectionner du texte pour qu'il soit copié, et un clic avec le bouton du milieu de la souris, c'est collé. Bref, c'est simple, clair, net, efficace. Sous Mac OSX, il faut faire <Touche dont je ne connais pas le nom>-C pour copier et <Touche dont je ne connais pas le nom>-V pou coller. Et là, 100 fois par jour, je me retrouve à souligner du texte pour le copier, puis quand je le colle, je me rends compte que ce n'est pas du tout cela que je voulais coller, et #!@%&?, il faut effacer le texte que je viens de coller, et resélectionner le texte qui m'intéresse, faire <truc>-C, <truc>-V, et tout ca pour un simple copier-coller.

J'ai eu beau chercher sur Internet, je n'ai rien trouvé pour avoir le copier-coller façon UNIX sous Mac OSX. Si quelqu'un a la solution, je suis prêt à lui payer une pinte de bière.

Notes

[1] http://yro.slashdot.org/yro/04/02/25/1346201.shtml

SEPT RAISONS POUR LESQUELLES JE CONTINUE A UTILISER TEMPLEET ALORS QUE JE POURRAIS UTILISER RUBY ON RAILS

M'enfin ?!? — Sun, 23 Sep 2007 16:15:00 +0200

Je m'occupe du site LinuxFR.org. C'est codé avec le merveilleux framework Templeet. Le site pourrait être refait avec Ruby On Rails, mais je vais vous expliquer en 7 raisons pourquoi je préfère Templeet ^[1] :

#1 - Templeet fait tout ce dont j'ai besoin

Qu'est-ce que Ruby on Rails peut faire que Templeet ne peut pas faire ?
... je réfléchis ...
Bon, en fait, la liste est longue, mais est-ce que j'ai vraiment besoin de tout ca ? C'est vrai qui se sert de Jabber, OpenID, de validation automatique de formulaire ou encore d'AJAX ? Sur LinuxFR.org, on utilise rien de tout ca, c'est donc que je n'en ai pas besoin.

#2 - Les vrais hommes travaillent directement sur la prod

Sur LinuxFR.org, on travaille directement sur le serveur de prod. On est des vrais hommes, on n'a pas besoin d'un serveur de dev. Puis, franchement, changer les habitudes du jour au lendemain, ce serait trop dur.

#3 - La vie serait trop monotone sans les bugs templeet

J'admire l'équipe qui développe Ruby on Rails, travailler en permanence sur du code testé et qui fonctionne correctement, ca doit lassant. Pour ma part, je préfère travailler avec les bugs de templeet, sans tests unitaires. C'est beaucoup plus joyeux :)

#4 - Templeet, c'est super performant

Vous ne me croyez pas ? Et pourtant, un benchmark a prouvé scientifiquement que Templeet est plus rapide qu'Apache : https://linuxfr.org//2003/04/07/120.... Alors que Ruby on Rails, c'est bien connu depuis l'affaire twitter, ca scale pas.

#5 - J'aime la syntaxe LISP

Avec Templeet, pas de risque de se reposer sur un éditeur de texte : je fais tout de tête, y compris compter les parenthèses. Ainsi, l'édition du code repose uniquement sur moi, et je peux faire exactement ce que je veux.

#6 - Configurer templeet, j'en rêve la nuit

A propos de ce que j'aime, la configuration de templeet, c'est que du bonheur ! Je passe des nuits à imaginer des solutions pour éliminer ce templeet.php de l'URL ou à réfléchir sur des algorithmes évolutionnaires pour ajuster les variables templeet.

#7 - Les sites web c'est comme les petites amies : je veux être le seul à m'en occupper

Avec templeet, je suis sûr de n'avoir jamais à partager mon site web avec qui que ce soit.

Notes

[1] Ce texte est une parodie de http://www.oreillynet.com/ruby/blog...

Copier-Coller depuis ViM

M'enfin ?!? — Tue, 11 Jul 2006 00:15:00 +0200

Dans mon dernier billet, j'écrivais que je rédige mes billets avec ViM, puis que je fais un copier-coller vers l'interface web de Dotclear. Pour cela, je fais la combinaison de touches suivantes :

gg      Aller au début du fichier et
"*      utiliser le registre "* pour ...
yG      ... copier le texte jusqu'à la fin du fichier.

Et comme le registe "* correspond au clipboard, je peux ensuite coller mon texte dans mon navigateur web (firefox).

Mais pour ce post, j'ai décidé de suivre le conseil de Romuald et d'utiliser l'extension Mozex, et à première vue, ca paraît pas mal.

Mise à jour : bon, en fait, j'ai un problème d'encodage avec mozex, mais j'espère bien le régler.

Coloration syntaxique dans Vim pour les billets Dotclear

M'enfin ?!? — Sun, 09 Jul 2006 23:25:00 +0200

Je ne sais pas pour vous, mais moi, j'ai horreur de devoir taper du texte dans mon navigateur web. Aussi, dès que je tape plus de quelques lignes, j'utilise ViM, puis je fais un copier-coller vers firefox. Cela me permet par exemple de profiter de la coloration syntaxique.

En particulier, je tape mes billets sous ViM, et je me suis donc créé le fichier de syntaxe pour là aussi avoir la coloration syntaxique. Ce fichier est téléchargeable ici : dotclear.vim Il faut le placer dans le répertoire ~/.vim/syntax/.

Et pour que ViM sache automatiquement que les fichiers avec l'extension .dc sont au format dotclear, il suffit de créer un fichier ~/.vim/ftdetect/dotclear.vim avec le contenu suivant :

au BufRead,BufNewFile *.dc  set ft=dotclear

Templates dans vim 2 / 2

M'enfin ?!? — Sun, 09 Jul 2006 21:44:00 +0200

Voici la suite du précédent tips.

Comme promis, nous allons donc voir comment avoir des templates un peu plus dynamiques. Le langage de script de vim n'étant pas des plus sympathiques, je préfère appeler un programme externe. Pour cela, nous allons remplacer la ligne que nous avions insérée dans le fichier vimrc par celle-là :

au BufNewFile * 0r! ~/.vim/skeleton.rb

Ici, c'est un script en ruby (skeleton.rb) qui est appelé. Pour le moment, ce script ne reçoit aucun paramètre. Pas terrible pour savoir quel template utiliser ! Pour régler ce problème, nous pouvons passer par exemple le nom du fichier, avec son chemin complet. Il suffit de rajouter %:p toujours à la me ligne du fichier vimrc. % indique le fichier courant, et :p est un modificateur pour avoir le chemin complet.

Mais, ViM fait déjà de la détection de filetype, aussi il peut être intéressant de passer ce filetype à notre script. Pour cela, nous allons encore modifier notre ligne :

au BufNewFile * :exe("0r! ~/.vim/skeleton.rb %:p " . &filetype)

Note : comme il n'est pas possible à ma connaissance de passer directement le filtype à la commande r!, je construit d'abord la chaîne de cractère avec toute la commande et le filetype, puis je l'éxécute.

Maintenant que nous pouvons appeller un script avec le chemin du fichier et son filetype, je pense qu'on peut dire que c'est gagné. Voici à titre d'exemple le script que j'utilise :

#!/usr/bin/env ruby
# Author: Bruno Michel <bmichel@menfin.info>
# Licence: MIT <http://www.opensource.org/licenses/mit-license.html>

require 'erb' 


SKELETON_DIR = File.expand_path("~/.vim/skeleton");
EXTENSION  = "erb"

file, filetype = ARGV
filename  = File.basename(file)
skeletons = [filename, filetype]
skeleton  = skeletons.map { |s|
    File.join(SKELETON_DIR, "#{s}.#{EXTENSION}")
}.find { |s|
    File.exist?(s) && File.readable?(s)
}

exit if skeleton.nil?

File.open(skeleton) do |f|
    puts ERB.new(f.read, nil, '<>').result(binding)
end

Note : si vous voulez utiliser ce script, n'oubliez pas de le rendre exécutable (chmod a+x ~/.vim/skeleton.rb)

Ce script va chercher un fichier .erb dans le répertoire ~/.vim/skeleton dont le nom correspond soit au nom du nouveau fichier, soit à son filetype. Et dans ce répertoire, on trouve, par exemple, ruby.erb :

#!/usr/bin/env ruby
# Author: Bruno Michel <bmichel@menfin.info>
# Licence: MIT <http://www.opensource.org/licenses/mit-license.html>

ou README.erb :

<%= `figlet -c README` %>
<%# figlet: http://www.figlet.org %>

Author: Bruno Michel <bmichel@menfin.info> 
Date: <%= Date.today.strftime("%d/%m/%y") %> 
Time: <%= Time.now.strftime("%H:%M:%S") %>
<% directory = File.dirname(file) %>
Project: <%= File.split(directory).last %>

Et voilà, mission accomplie, nous avons des templates dynamiques, avec notamment la possibilité d'insérer la date ou l'heure courante.