Voila, comme dit dans le billet précédent, je vais donc faire deux billets de django app de mai, ça m’apprendra à être en retard.

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.