Nautilebleu

Authentification avec django_hg

La semaine dernière [fr], j’ai réussi à utiliser django [en] pour répondre aux commandes de Mercurial.

L’étape suivante dans cette logique était donc de faire l’authentification grâce à django. Le code a été poussé sur bitbucket [en] hier soir. Je n’ai par contre pas eu le temps d’écrire la documentation, j’espère pouvoir faire cela dans la journée.

Si l’authentification est finalement contenue dans un decorator, j’ai fait pas mal d’administration pour mettre en place un environnement de développement. En effet, j’ai tout d’abord configuré Apache pour qu’il serve django. Cela n’a pas été sans mal, car la configuration de mod_wsgi m’a donné un peu de fil à retordre.

La documentation officielle de django [en] recommande d’utiliser mod_wsgi [en]. Je me suis donc tourné vers cette solution. Malheureusement, la version distribuée par MacPort [en] est vieille (version 1.1 alors que nous en sommes à la 2.5 en stable et que la 3.0 est en RC) et surtout elle est couplée à Python2.4, alors que django utilise Python2.5. J’ai donc dû en passer par la compilation.

La documentation de mod_wsgi est très bien faite et elle explique bien les problèmes que l’on peut rencontrer avec MacOSX [en], essentiellement dû au fait que MacOSX supporte 4 architectures (PPC7400 — 32 bits —, PPC64 — 64 bits —, i386 — 32 bits— et x86_64 — 64 bits) mais que tous les programmes ne sont pas forcément distribués avec les 4 codes. En l’occurence, Apache et Python ont été compilé en i386 uniquement… mais voilà, même si on lui indique le chemin de Python a utilisé, le compilateur va chercher à un moment donné celui installé par défaut. En l’occurence, il s’agit d’une installation via MacPython, effectuée sur mon précédent Mac, avec un code PPC7400. Il m’a fallu un peu de temps avant de m’en rendre compte et remplacer le fichier PPC par un fichier i386 et permettre à la compilation de se terminer.

Du coup, entre temps, j’ai installé mod_python pour pouvoir avancer un peu sur la configuration de django via Apache. Pas de remarque particulière, l’installation se fait sans difficulté via MacPort et la configuration ne m’a pas posé de problème particulier, y compris l’authentification HTTP via Apache, django proposant un backend [en] pour cela. Ceci étant, ce n’était qu’une solution très provisoire, car mod_python ne permet pas d’utiliser Mercurial via django. En effet, le principe de django_hg est d’utiliser la requête django pour construire une requête Mercurial qui est en fait une requête wsgi. Ca fonctionne avec le serveur de développement de django car celui-ci est également wsgi. Évidemment, ce n’est pas le cas lorsque django est servi via mod_python.

D’où mon retour sur mod_wsgi. Une fois la compilation réussie, la configuration m’a donné un peu de mal également. En fait, là aussi, la doc est très claire, encore faut-il penser à vérifier le chemin de django. En effet, si django n’est pas dans le path du dossier où est exécuté le script wsgi, il faut ajouter django à l’aide de sys.path.append("/chemin/vers/django/"). Cependant, le piège par rapport aux exemples de la doc, c’est qu’avec MacPort, django est installé dans opt/local/lib/python2.5/site-packages/django/bin/. Or si on inclue juste opt/local/lib/python2.5/site-packages/django/, on peut inclure django, accéder aux settings, mais le script crash après. Mais si l’on lit bien la documentation, il est bien précisé qu’il faut mettre le chemin où se situe django-admin.py. Voilà qui m’apprendra à lire les documentations au pied de la lettre !

Cela fait, le reste a été un jeu d’enfant, mais je réserve le détail à un prochain article.