Cette Djangocon est également la première Cong qui n’était pas un événement autonome mais un événement à l’intérieur d’un autre événement (à savoir le capitole du libre). Je dois avouer que je suis assez partagé sur cette solution de l’événement dans l’événement. Effectivement cela permet d’attirer ‘des curieux’ qui viennent papillonner le temps d’une conférence ou d’un atelier (le nombre de 64 personnes dans l’auditoire a d’ailleurs été atteint). Cela permet aussi d’assister à une conférence de Jérémie Zimmermann la fin du premier jour. Enfin, cela permet de diminuer la charge de travail pour les orgas. Mais cela aussi signifie ne pas être mettre de tout les choix (essentiellement logistique) et de devoir gérer les interactions avec l’organisation globale. Je suis donc partagé sur ce mode d’événement à l’intérieur d’un autre.

Mais venons en maintenant au Djangocon en elles mêmes. Tout d’abord le programme. LT et conférences étaient très intéressants. La rafale de huit conférence l’après midi, conférence de 20 minutes plus 5 minutes de questions auraient pu être difficile à encaisser mais les conférences étant intéressantes et les orateurs d’un bon niveau, tout est passé comme une lettre à la poste.

Étonnamment, les ateliers et sprint du dimanche matin furent même plus productif que ce à quoi je m’attendais. Et l’organisation ‘au dépoté’ (en tout cas ce n’étais pas indiqué dans le programme) d’un atelier d’initiation était une excellente idée. Cela confirme à nouveau mon sentiment qu’il y a une forte demande concernant des initiations à Django et que c’est des choses que les ‘anciens’ de la communauté, les sachants, doivent mettre en place pour partager leur connaissance et jouer le rôle de ‘mentor’.

Alors effectivement, il y a, à mon sens des choses améliorables au niveau logistique, comme l’approvisionnement en jus de fruit / café / eau ou le repas/soirée du samedi soir, mais ce n’est pas si grave que cela (et on revient à mon premier point, le fait de s’intégrer dans un événement plus grand).

Les points positifs importants que je retiens de cette conférence sont :

• avoir des conférences non totalement centré sur Django est une excellente chose. À Rennes il y avait une conf sur cherrypie et circus, à Toulouse une conf (différente de celle de Rennes) sur circus aussi et ça permet d’ouvrir un peu ses œillères.
• Les ateliers débutants sont des choses à mettre en place. Se pose la question de les mettre en place dans des Djangocongs d’une taille plus importantes.
• La soirée du samedi soir est un point très important, de mon point de vue. Les soirées jeux de plateau remportent mes suffrages, pour l’instant.
• Sprint et ateliers le dimanche matin peuvent être efficaces. Peut-être que la solution est d’en décaler leur démarrage en prenant en compte le besoin de sommeil.

Ces Djangocon sont à mon sens un beau succès et j’ai vraiment été très heureux d’y être. Je profite de ce billet pour, à nouveau, remercier les organisateurs et les orateurs. (Et ce fut assez rigolo de se rendre compte qu’il y avait des ponts très intéressant entre les 2 djangocon Rennes et Toulouse, comme par exemple  une présentation de tastypie à Rennes, suivi d’un atelier Tastypie à Toulouse ).

• matin conférence
• début d’après midi LT
• reste de l’après midi barcamp ou atelier d’initiation

Pour une première conf, et conf régionale qui plus est, je trouve que le public fut au rendez-vous. 27 personnes pour les conférences, c’est en effet une belle réussite. Pour l’occasion, la cantine numérique de Rennes avait prêté ses locaux toutes la journée, ce qui a permis de mettre en place les conférence du matin et l’atelier initiation du matin (les barcamps se passant à quelques dizaines de mettre à la maison des associations)

Ce que je retiens de cette rencontre régionale (hormis le fait qu’à rennes, il pleut tout le temps) c’est :

• il peut être difficile d’avoir des conférenciers locaux, il suffit alors de les faire venir d’ailleurs (mais il y a eu un certain nombre de conférencier ‘du cru’ et ça fait plaisir)
• la partie barcamp est une partie toujours très intéressante et qui fonctionne vraiment bien
• l’atelier d’initiation était une première, jamais encore cela n’avait eu lieu dans une rencontre django. Le public était restreint (6 à 8 personnes) mais j’ai l’impression que c’est un format qui fonctionne et qui réponds à une vrai demande des gens, un vrai plus de cette édition bretonne, et qu’il faut, à mon avis, répliqué, à minima, dans les autres éditions régionales.
• Lors des djangocong 2012, certains pensaient que les rencontres régionales allaient ‘faire se relâcher la pression sur la conférence nationale’. A priori, si je généralise à partir de l’exemple de cette première conférence régionale, c’est l’inverse qui va se passer. Les gens qui ‘goûtent’ aux rencontres django régionale, dés qu’ils apprennent qu’il y a des ‘grosses rencontres’, veulent absolument y aller.
• Le soir c’était free style, une bonne partie des gens se sont retrouvés dans un bar à jeux pour siroter une bière en jouant à des jeu de plateau. Et ce fut excellent. Le format bire et jeu de plateau testé pour la première fois en 2011 montre encore une fois qu’il est un excellent format (voir le meilleur) en ce qui concerne les soirées post conférences (ou inter pour des confs de 2 jours).
• J’avais peur que les rencontres régionales ne soient que des espèces de mini grandes djangocong, avec uniquement des ‘vieux’ djangonautes présents. Ce ne fut pas le cas et c’est tant mieux.

En résumé, ce fut une excellent première édition et j’ai hâte de voir ce que donnera la deuxième édtion (si il y en a une).

En tout cas merci à Exirel d’avoir organiser tout cela, à la cantine numérique de Rennes d’avoir participé à l’aventure des django en bretagne, aux auditeurs d’être venus faire des conférences de qualités et aux rennais d’avoir répondu présent.

Et à la semainse prochaine pour DjangoCassoulet à Toulouse !!!!! Espérons qu’il y aura des pains au chocolat !

J’en ai profité pour donner mon avis sur la question. A savoir qu’à mon sens, les serveurs webs n’était pas fait du tout pour gérer des connexions en mode connecté. Parce qu’ils n’ont pas été prévu pour cela. Idem pour le cœur de django qui n’est pas fait pour garder des pools de sockets, des états par connexion clientes, etc etc …

Alors qu’à contrario il y a des frameworks (je pense à twistted mais pas seulement) ou des manières d’écrire des serveurs qui permettent de gérer proprement des communications en mode connectées.

Il me semblait donc logique de ‘sortir’ la partie websocket du cœur de Django pour qu’elle soit gérer par ‘autre chose’. Il me semble qu’à la fin de ma tirade explicative, quelqu’un m’a dit ‘ben ok, fait le’ (me demande même si ce n’est pas ce fourbe de n1k0)

Du coup, ben ayant eu un peu de temps, ces jours-ci, j’ai rapidement fait un proto merdique de test.

Le principe a été de prendre l’exemple de simple chat de Gevent-SocketIO et de le ‘transformer’ en une commande de management Django. La commande de management simulant un serveur de gestion des connexions socketIO des utilisateurs. Du coté django, on a une première vue qui demande de donner un nickname puis on se retrouve sur la fenêtre de chat (qui utilise socketIO) et on peut discuter avec les autres connectés. J’ai rajouté deux petits trucs, pour le plaisir, le fait d’avoir les 5 dernières lignes de discussion (ça se récupère par la partie WebSocket) et le nombre de user et lignes de discussions totales (s’affiche la première fois par la connexion HTTP classique, se met à jour par les WebSocket)

Il faut donc à un moment ou un autre, lier la partie DjangoWeb de la partie SocketIO. Comme ce n’est qu’un prototype pour m’amuser, je passe à la vue de chat une key généré aléatoirement, key que me renvoie le client JS à travers la websocket.

Bon, bien entendu, tout cela n’est qu’un prototype pour expliquer (avec du code) la manière dont je voyais les choses. Bien entendu bis, il faudrait ‘lier’ la partie Web classique et Websocket d’une meilleure façon, ne pas utiliser une commande de management brute de décoffrage, potentiellement  élaguer pas mal gevent-socketio pour enlever tout ce dont on n’aurait pas besoin, etc etc …

Mais voilà, j’avais juste envie de faire un test, d’en parler ici et de vous demander votre avis sur la question:)

Deux première initiatives ont été finalement été lancés :

• DjangoBreizh à Rennes (vive la Bretagne, le temps pourris, le cidre et les crêpes) le samedi 17 novembre.
• DjangoCon Toulouse (ils ont oublié un g à la fin du nom.. tss tss, mais bon vive le cassoulet) le 24 et 25 novembre.

C’est avec une grande joie que j’ai vu naître ces deux initiatives locales (d’ailleurs je serais présent, d’une manière quasi certaine à Rennes et peut-être, mais vraiment peut-être à Toulouse). Parce que ce n’est pas forcément évident d’organiser des conférences, même ‘juste locale’. Et que même dans certains domaines, il me semble que c’est plus difficile d’organiser une conférence locale que nationale.

Et un point qui peut, peut-être, être problématique, c’est la visibilité moindre de ces conférences, qui fait que mécaniquement, il y a moins d’orateurs potentiels qui en entendent parler et donc moins de propositions.

D’où mon billet du jour. Parce que pour réussir une bonne conférence, il faut une équipe organisatrice, un public et des orateurs. Et d’une vision tout à fait extérieure, j’ai vu peu de gens twitter ‘j’ai proposé ma conf pour DjangoToulouse ou DjangoBreizh’. C’est sûrement du au fait que conférences régionales dit moins de visibilité … (mais je l’ai déjà dit ça). Mais ça n’en reste pas moins ennuyeux.

Donc pour essayer de donner un peu plus de visibilité, je me fends de ce modeste billet. Comme ça vous ne pourrez plus dire que vous n’étiez pas au courant. Parce que maintenant vous l’êtes.

Alors proposez vos conf !

Pour les fainéants, je mets les liens direct vers les appels à conférences :

• Pour DjangoBreizh
• Pour DjangoToulouse

Voici la méthode que j’ai utilisé. Je suis preneur de toute amélioration que vous pourriez me remonter sur ma manière de faire (pour le jour où j’aurais vraiment besoin d’installer des choses pour faire de la prod avec du virtualenv). D’ailleurs je la partage ici autant pour le plaisir de la partager, que pour ne pas l’oublier que pour vous permettre de l’améliorer.

Le commencement, installer virtualenwrapper. En local sur son home. En faisant :

pip install --install-option="--user" virtualenvwrapper

du coup cela vous installe le tout dans $HOME/.local/….

Une fois installé, il faut faire (comme pour installation normale) la création du répertoire de vos environnements en faisant :

export WORKON_HOME=$HOME/.virtualenvs
mkdir -p $WORKON_HOME

Ensuite histoire de ne plus avoir à le faire, dans votre .bash_profile :

export PYTHONPATH=~/.local 
export WORKON_HOME=~/.virtualenvs 
export PATH=$PATH:$PYTHONPATH/bin 
source ~/.local/bin/virtualenvwrapper.sh

un petit coup de

source ~/.local/bin/virtualenvwrapper.sh

et Voila ! (à dire comme avec l’accent d’un américain qui prend un accent français).

Vous aller pouvoir faire des mkvirtualenv en veux tu en voilà !

(Un petit tips, si vous faites du django, il ne faut pas oublier dans votre django.fcgi d’ajouter une ligne

 sys.path.insert(0,'/home/$USER/.virtualenvs /VENV_NAME/lib/python2.6/site-packages'

)

Donc, pour la troisième année les Djangocongs ont lieu, à nouveau dans le sud. Mais cette année ce ne sera pas à Marseille (après tout il faut bien vous faire découvrir de nouvelles villes) mais à Montpellier pendant le week end du 14-15 avril.

Du coup, le staff s’élargit et accueille :

• des locaux (nico et stéphane pour ne pas les nommer), véritables supermens de l’organisation, qui avec l’agilité qui les caractérisent s’occupent de tout et du reste. (Enfin c’est tout de même moi qui continue à faire les factures que les gentils sponsors vont recevoir, des sousssssss)

• pleins de bonnes volontés, qui ont décidés que pour la troisième, il était temps de montrer qu’eux aussi avait des biscottos sous le tee-shirt geek et ont très gentiment proposés leur aide.

Un staff élargi qui se retrousse les manches pour que cette troisième édition soit plus qu’un succès, soit une apothéose.

Et pour cela, plusieurs choses :

• la retour du découpage en quatre temps, avec simplement quelques arrangement pour parfaire le tout
• une unité de lieu, … enfin.
• Un lieu juste magique,.. les pieds dans l’eau, au bords de la plage, l’eau turquoise, les palmiers, le ciel bleu, le sable fin (et si il pleut ça sera à cause des nordistes).

Mais pour que cette troisième édition soit vraiment une édition mémorable, une édition totalement gaga, il va falloir que toi, cher lecteur, tu y mettes un peu du tien. Bien sur il faudra t’inscrire, des que cela sera possible (mais ne t’inquiète pas, tu seras au courant). Bien sur il faudra ne pas oublier de prendre tes billets de train, ton ordi et ton maillot starwars.

Mais vous pouvez faire plus . Pour cela rien de plus simple,  il va falloir prendre son courage ponifique à deux mains et proposer un sujet de conférence (ATTENTION, tu n’as que jusqu’au 13 janvier). Vous ne savez pas de quoi parler ? Vous avez l’impression de ne rien avoir à dire ? Si vous utilisez django, vous vous trompez sûrement. Je suis sur que vous avez un retour d’expérience enrichissant pour tous et que vous allez pouvoir partager en douze minutes. Vous avez utilisé django dans un contexte non web, fait des zigouigouis avec HTML5 ou de la haute dispo, lancé le dev d’un module utilisé par la terre entière et vous avez du coup une vraie expérience de lead de projet avec des utilisateurs ??? Vous voyez que vous en avez des choses à nous apprendre.

Vous ne vous reconnaissez dans aucune des phrases du dessus ? C’est pas grave, vous avez sûrement autre chose à nous raconter. Et en plus, comme on est conciliant, si vous avez peur que douze minutes cela soit trop pour vous, si vous êtes plus du genre 5 minutes douche comprise, alors vous allez être aux anges. Parce que vous aller pouvoir candidater pour un LT de 5 minutes. Le monde est bien fait non ?

Et si vraiment, vraiment tu penses que cette année, non, tu ne peux proposer un sujet, ce n’est pas grave. Après avoir passé une bonne demi journée à apprendre en écoutant des conférences qui seront, forcément, super intéressantes tu pourras participer jusqu’à plus soif (non je parle pas de l’apéro…) lors des sessions de barcamp et de sprint. Sans oublier la dernière demi journée qui te permettra de faire le fou sur la plage (ou tout autre activité ne nécessitant pas de haut de forme).

Plus que 150 jours ….

Ps : pour ceux qui n’ont pas reconnu la référence du titre : www.youtube.com/watch?v=lxn48wSiCzg
Ps2 : merci à stéphane de m’avoir fait découvrir Mari Kasurinen

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Deux possibilités pour le trouver, sur sa page github (on regrettera le choix de github et non bitbucket mais bon:) )  ou sur sa page pypi. Ce qui du coup vous permettra de l’installer de deux façon :

• un petit git clone bien de chez nous
• un simple : pip install django-ratelimit-backend

La doc est dispo sur la page readthedocs du projet. Et elle est bien fournie. Une aide à l’install, un quickstart et une section pour expliquer comment modifier le critère de limitation et une référence complète du code.

2- Mais au fait, à quoi ça sert ?

A empêcher les vilains méchants pas beau de crier ‘des logins ou un sort’ devant vos jolis sites webs Django. En clair, à ‘bannir’ pendant 5 minutes des IP qui auraient tentées de se logguer sur votre appli à de trop nombreuses reprises.
Les réglages de base sont :

• si tu tentes de te logguer 30 fois sans y arriver
• dans une période de moins de 5 minutes
• alors tu es bannis 5 minutes.

3- Comment ça marche ?

C’est relativement facile.
Première chose, il n’est même pas nécessaire d’ajouter l’app dans vos INSTALLED_APPS, à part si vous voulez lancer les tests (vous pourrez alors installer tox si vous voulez tester avec toutes les versions de django)

Il vous faudra par contre ajouter un backend d’authentification à savoir :  ‘ratelimitbackend.backends.RateLimitModelBackend’.

Il vous faudra de plus :

• utiliser la vue ratelimitbackend.views.login à la place de django.contrib.auth.views.login
• si vous utilisez l’admin, utiliser ratelimitbackend. admin au lieu de l’admin normal de django.
• Ajouter le middleware ratelimitbackend.middleware.RateLimitMiddleware

Vous pourrez bien entendu modifier les critères de détection de vilains. Pour cela il vous suffira d’implémenter votre propre middleware (tout est bien expliqué dans la doc, ne paniquez pas!)

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Où est ce qu’on le trouve, sur son site web, sa page pypi et sa page github.

Pour l’installer, vous aurez plusieurs plusieurs solutions :

• un git clone tout simple
• un petit pip install en utilisant le support git de pip
• un petit easy_install ( ou pip install normal) pour avoir la dernière version stable.

Niveau démo, il existe et c’est carrément cool :

• une démo du rendu (qui sert à héberger la doc)
• une démo de la version d’administration.
• Un planet qui liste tous les blogs utilisant Zinnia

Concernant la doc, elle est vraiment super bien foutue et très complète. Installation, Configuration, Configuration avancée, extensibilité, etc etc … C’est vraiment une des meilleures docs d’application django que j’ai pu lire. Pour ne pas dire la meilleure d’ailleurs.

Cerise sur le gâteau, on peut même voir la couverture de code des tests.

2- Mais au fait, à quoi ça sert ?

Bon, je l’ai dit c’est un moteur de blog. Donc on a des catégories, des billets, des tags, et des flux RSS.

Mais ce n’est pas tout, Zinnia propose vraiment pas mal de petites fonctionnalités qui en font un vrai moteur de blog, qui (et je le dis sincèrement) peut imaginer concurrencer certains moteurs de blogs php très connus.

Zinnia offre par exemple :

• des url shortenners
• de la publication de tweets automatique sur publication d’article
• un moteur de recherche interne
• détection des spams avec askimet (ou autre)
• des sitemap
• des channels, un truc spécifique à Zinnia
• une extension facile, ….

Et si vous avez déjà un blog ? Genre WordPress ou Blogger ?

Et ben Zinnia offre des moulinettes d’import / export. Et ça, c’est vraiment terrible.

3- Bon et en conclusion ?

Il y a a mon sens plein de bonnes idées dans Zinnia :

• Les script d’import / export sont tout simplement un must have qui vont que l’on peut vraiment imaginer migrer un blog existant sous Zinnia.
• Les channels qui permettent de réutiliser le moteur de recherche interne (qui utilise pyparsing) pour faire des recherches parmis les articles et en sortir une partie.
• Les models qui sont bien fait, à base de classe abstract et permettent de surcharger sans difficulté les choses.
• Il utilise south ce qui doit faciliter les migrations.

A tout cela il faut ajouter le fait qu’il n’y est au final que peu de dépendances. Au niveau des apps django, il n’y a que deux dépendances obligatoires :

• django-mptt
• django-tagging

Après cela dépends des fonctionnalités que vous voulez mettre en place, mais cela reste très light et très clair. (je ne parlerais pas par exemple de pinax qui en comparaison me fait l’effet d’une usine à gaz).

Je vais donc suivre ce projet avec intérêt et même si je ne suis pas sur de passer tout de suite le mad blog en Zinnia, je vais en migrer d’autre d’ici quelques temps, ça, c’est certain.

Espérons que la django app du mois d’aout soit à l’heure…. En attendant de voir si en août, à l’heure je serais, je vous propose de découvrir cette petite django-app bien sympatique.

Mais avant un peu de contexte. Je cherche depuis quelques temps une django app pour faire de l’autocompletion. Djangopackages qui est décidément très souvent mon ami propose un tableau récapitulatif assez sympa d’un certain nombre d’app qui propose cela.

Parmi la liste, j’ai décidé de tester django-autocomplete qui me paraissait le mieux répondre à mes besoin, à savoir de l’autocomplete facile coté admin, comme coté site non admin.

Nouveauté ce mois si au niveau du billet, je vais vous présenter deux versions de l’app à savoir la version ‘officielle’ faite par tyrion et un fork fait par etienned. Pourquoi vous présentez deux versions ? Parce que la version d’etienned propose quelques améliorations visuelles intéressantes (et quelques petits refactor pas débiles).

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Ici cela dépends de la version que vous désirez tester de django-autocomplete. Si vous voulez tester la version première de tyrion alors vous avez  deux possibilité :

• par un petit hg clone à partir de sa page bitbucket
• en utilisant easy_install ou pip.

Par contre pour la version d’etienned, pas de package, donc pas d’easy_install ou de pip, il n’y a qu’une solution, un bon vieux hg clone

Chose suffisamment rare pour qu’elle soit mis en avant, il y a une démo de la version première, que vous pourrez tester ici.

Concernant la doc, pour les deux versions, tout se trouve dans bitbucket.

• Dans la version de tyrion vous aurez droit au fichier Readme et au wiki.
• Dans la version d’etienned il n’y a que le fichier Readme qui est composé en grande partie du descriptif des addons que propose ce fork (et qui se finit par un exemple d’utilisation dans l’admin).

Est ce que c’est suffisant ? Si vous envisagez de n’utiliser l’autocomplétion que dans la partie admin, clairement oui. Sinon alors là, clairement non. Vraiment pas même. Et à vous les joies de la lecture du code source pour comprendre comment cela fonctionne (ou alors vous pouvez continuer à lire mon billet et voir comment tout cela fonctionne dans la partie 3 ).

2- Mais au fait, à quoi ça sert ?

Tout simplement à proposer un mécanisme d’autocomplétion sur les champs texte ou Int mais aussi  les foreignkey et les manytomany. Et qui, cerise sur le gâteau, ce veut simple au niveau de son déploiement

Et à le faire d’une façon un peu ‘magique’. On déclare seulement quels sont les models qui mettront en place l’autocomplétion et pour lesquels de leur champs. Et après tout ce fait presque tout seul (en tout cas pour la mise en place des urls qui permettent de retourner le résultat du filtrage en fonction des caractères tapés, c’est tout automatique).

3- Comment ça marche ?

C’est presque tout simple.  En tout cas si vous voulez intégrer django-autcomplete dans l’admin.

Imaginons que vous vouliez autocomplete les auteurs de bouquin dans une app de critique de livre.

Vous allez commencer par déclarer une classe qui configure votre autocomplete :

Ensuite ?

Vous déclarez simplement où vous voulez utiliser votre autocomplete. En partant du principe que votre model pour les reviews de bouquin s’appelle Reviews et que le champ pour l’autheur du bouquin s’appelle book_author cela donnera cela :

et voilà. C’est fini. Vous avez dans votre admin, un champ ForeignKey en autocomplétion. Et sans forcer.

En lisant la doc vous verrez que l’on peut faire de façon différente, spécifier le queryset sur lequel on veut limiter l’autocomplete, etc etc …

Maintenant, qu’est ce qui se passe si vous voulez mettre un peu d’autocomplétion dans votre site version pas admin ?

Hum ben là, c’est pas beaucoup plus compliqué en fait. Le problème est juste qu’il n’existe pas de doc.
Mais si vous farfouillez dans le code vous verrez qu’il existe une classe de widget (AutocompleteWidget qui se trouve dans  autocomplete.widgets qui permet de mettre en place l’autocomplétion).

Il vous suffit alors dans votre formulaire, de rajouter le paramêtre widget à votre Field et de lui passer un AutocompleteWidget (qui a lui même en paramètre le champ qui mettra en place l’autocomplétion).

Si l’on reprend l’exemple d’au dessus on pourrait avoir quelque chose ressemblant à cela :

Il y a bien évidement le widget qui va bien pour la version multiple sélection (MultipleAutocompleteWidget)

Et si l’on continue à fouiller un peu plus, dans utils, on trouvera une très sympathique autocompleteform_factory qui permet de générer un form en prenant un paramètre le Model qui va bien, un dictionnaire listant les champs implémentant l’autocomplétion
ainsi que les champs à exclure.

4 conclusion et tips.

J’ai eu quelques problèmes lors de mes tests lorsque j’ai voulu installer django-autocomplete en temps qu’app dans le répertoire de mon projet et pas dans mon pythonpath. J’avais des phénomènes bizarre de double exécution de code qui me donnais de jolies exception. Je n’ai pas vraiment réussi à comprendre le pourquoi du comment ni pourquoi en sortant simplement l’app du répertoire de mon projet cela se mettait à fonctionner parfaitement…

Pour ceux qui utilisent grappeli, je viens de voir qu’il existait un fork de django-autocomplete pour en faciliter l’intégration. Mais par contre, là, je n’ai pas du tout essayé.

Ha et pour finir, le titre est une référence un peu obscure à un film avec Jack Black:).

Ce mois-ci, enfin le mois dernier, je vais vous présenter Impostor une application que j’ai découvert au détour d’un tweet (de dzen je crois )

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Deux possibilité pour le trouver, sa page github ou sa page django packages. Pas de page pypi, enfin pas encore, espérons qu’elle arrive vite.

Pour l’installer, pas le choix, il faut passer par github.
Un petit git clone https://github.com/samastur/Impostor.git et c’est plié.

Quand à la doc, Elle se limite au readme.rst. Mais cela suffit. Et puis le readme est bien clair. Il vous expliquera comment l’installer dans votre projet django et comment vous en servir (et puis si vous continuer à lire, je vous l’expliquerais aussi)

2- Mais au fait, à quoi ça sert ?

Tout simplement à se déguiser lorsque l’on se logue. D’ailleurs c’est un des meilleurs noms d’app django que j’ai pu croiser. Décrivant à la fois bien la finalité de l’app tout en étant rigolo.

Impostor vous permettra donc, si vous avez un login staff member de vous loguer en temps qu’un au tre utilisateur. Vous verrez donc l’appli comme il la voit, vous pourrez interagir avec django en étant considéré comme l’utilisateur dont vous avez prit les traits (enfin le login).

3- Comment ça marche ?

C’est tout simple.
Il suffit d’ajouter un backend d’authentification à votre application django, à savoir ‘impostor.backend.AuthBackend’

ce qui doit vous donner quelque chose ressemblant à :

 AUTHENTICATION_BACKENDS = (
 'django.contrib.auth.backends.ModelBackend',
 'impostor.backend.AuthBackend',
 )

et bien entendu il faut ajouter ‘impostor’ à vos INSTALLED_APPS

Ensuite ?

Un simple petit syncdb et c’est fini, vous allez pouvoir vous déguiser en un de vos utilisateurs. Comment ?
Au lieu de vous loguer avec votre login il vous suffira de vous loguer ainsi :

 votrelogin as leloginquevousvoulezdevenir

et de taper votre password.

Donc la deuxième django app du mois sera django-urlcrypt. Une petite précision avant d’aller plus loin, c’est une des toutes premières fois où je vais parler d’une app sans avoir fait plus que la tester sur un projet de test, sans avoir d’idée précise de où ni comment je vais l’utiliser ‘en vrai’.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Alors on le trouve soit sur sa page pypi soit sur sa page github.

Pour l’installation là encore, les trois moyens habituels :

• par easy_install
• pip
• un petit git clone des familles

La doc, là c’est comme l’app précédente, elle est limitée au contenu de la page de pypi ou au fichier Readme.rst.

Bon alors c’est vrai que la doc est suffisante pour comprendre comment l’app marche, mais sur une app qui est aussi ‘sensible’, une bonne lecture du code ne fait pas de mal (c’est d’ailleurs ce que j’ai fait quand j’ai commencé à faire joujou avec).

2- Mais au fait, à quoi ça sert ?

En fait l’app a deux utilité même si une seule est vraiment mise en avant sur la doc de l’app. La première c’est de fournir aux utilisateurs une url ressemblant à ça :  http://www.mydomain.com/r/TkNJBkNFAghDWkdFGPUAQEfcDUJfEBIREgEUFl1BQ18IQkdDUUcPSh4ADAYAWhYKHh8KHBsHEw qui les authentifiera automatiquement et qui en plus les redirigera vers l’url que vous aurez voulu.  (genre le renvoyer sur /profil ou /inbox)

L’autre fonctionnalité moins mise en avant, c’est que l’on peut encoder des infos dans l’url, dans un message qui se trouve être un dictionnaire. Alors honnêtement je ne sais pas trop encore à quoi cela peut servir, mais je trouve l’idée coolos.

3- Comment ça marche ?

C’est tout simple.

Dans une vue, on peut utiliser la fonction urlcrypt.generate_login_token qui prend en param l’utilisateur et l’url de redirect et qui génére le token qui encode le tout. Ensuite il suffit de créer l’url complète qui va bien.

Dans un template, on utilise le template tags encoded_url qui prend comme argument un user et une url de redirect.

Enfin on peut utiliser les fonctions urlcrypt.encode_token et urlcrypt.decode_token
qui permettront de crypter / décrypter un message contenu dans un dictionnaire (voir l’aide pour plus d’infos).

Au niveau des configurations possibles, on peut configurer :

• à combien de requêtes à droit un visiteur
• l’url de fallblack si l’authentification contenu dans l’url echoue
• un path vers une clé privée RSA qui permettra d’ajouter un cryptage RSA lorsque l’on génère le token.  L’utilisation de ce paramètre est très très fortement recommandé (pour rappel pour généré le clé : ssh-keygen -t rsa -f )

4- conclusion

Le mécanisme de login par url cryptée me séduit beaucoup. Mais d’un autre coté je me pose des questions au niveau sécurité. Parce que l’url, l’utilisateur il va devoir la stocker. Et qu’autant mémoriser un mot de passe, on peut le faire, autant apprendre une url…, qu’en pensez vous ?

La question de la durée de vie de l’url me semble aussi importante. J’aurais aimé avoir dans l’app un système qui permette de rendre des url obsolètes parce que trop vieilles..

Enfin concernant la deuxième méthode d’utilisation, à savoir encoder des messages dans l’url, je trouve l’idée ravissante, j’ai envie de l’utiliser mais je ne sais pas à quoi elle pourrait bien me servir. A réfléchir donc.

UPDATE:

on vient de me pointer quelques problèmes qui existent avec cette app (discussion visible ici) Apparement un des problèmes a été réglé en utilisant RSA (mais son utilisation n’est toujours pas obligatoire) mais il me semble que le hash du password est toujours utilisé dans certain cas. Ce qui n’est vraiment pas une bonne idée. En l’état l’app n’est donc pas forcément à utiliser, mais plutôt à étudier pour imaginer son propre système.

Du coup, pour marquer, le coup, je publierais deux django app du mois de mai, même si je les publie en juin.

Et pour commencer, django-countries. C’est d’ailleurs assez rigolo parce que je parlais il y a peu de moyen de gérer les pays, avec une liste de choix existantes, etc.. et op, je tombe sur django-countries.

1- Où on le trouve, comment on l’installe, tout ça quoi (et la doc) ?

Vous trouverez django-countries soit sur sa page pypi soit sur sa page bitbucket.

Pour l’installation, vous avez les trois moyens désormais classique :

• un easy_install
• un pip install
• un bon vieux hg clone

La doc elle se limite à :

• la page pypi
• le readme du repository

Sachant que dans les deux cas, le contenu est le même. Mais vu la simplicité de l’app, cela suffit amplement.

2- Mais au fait, à quoi ça sert ?

L’app rajoute tout simplement un nouveau type de field, le CountryField. Ce CountryField vous permettra de gérer les codes à 2 lettres internationaux qui modélisent les pays mais aussi d’afficher un petit gif du drapeau qui va bien.

Et oui, comme dans les vrais sites et tout quoi.

3- Comment ça marche ?

C’est donc vraiment tout couillon. Un field CountryField. Et des instances de fiels qui ont les données membre :

• code (le code à deux lettres)
• name (le vrai nom du pays)
• flag (le chemin vers le drapeau)

Rien de bien compliqué.