ZEP-17 : Elaboration de l'API des membres

J'avoue ne pas comprendre la problématique ici. Le site à terme devra être un client de l'API, et comme n'importe quel client, il n'est là que pour servir de passerrelle entre l'utilisateur réel et le back-end du site.

Toute action effectuée sur le site dépend si l'utilisateur est connecté ? invité ? staff ? super-user ? Si on reprend le protocole OAuth résumé dans la ZEP, on retrouve bien chaque notion.

Pour information, la ZEP passe de l'état "Validation" à "Acceptée" suite au commencement de son développement.

Comme vous le savez, le travail est conséquent puisqu'il faut, dans un premier temps, refactoriser le code existant afin d'éviter la répétition de code entre les vues actuelles du site et les vues de l'API. Pour l'instant, gustavi prend en charge la refactorisation des vues du module des membres vers une approche CBV et je me charge d'intégrer l'API dans les vues qu'il refactorise. C'est une tentative de refactorisation, nous tenterons de la mener à terme mais c'est un travail conséquent et un grand merci à gustavi pour sa contribution plus que bienvenue sur cette ZEP.

L'ancienne PR a été fermée au profit d'une nouvelle branche sur le fork de gustavi. Si vous voulez nous aider, n'hésitez pas à vous manifestez via ce sujet afin que nous puissions nous organiser dans le développement. Toute aide est plus que bienvenue !

Je vous soutiens moralement, la Zep 12 me demandant deja pas mal de boulot.

Je crois que tout le monde vous soutient moralement, c'est vraiment une killer feature en devenir !

Salut à tous,

C'est bien de dire que nous avons commencé mais avoir des petits récapitulatifs de l'avancement, c'est mieux. Donc nous avançons bien. gustavi a initié le refactoring des vues du module des membres et s'est renseigné auprès de la communauté Django pour être un peu aiguillé. Il en résulte que ça se serait ridicule de tout switcher sur une approche CBV dans nos vues et que c'est plus intéressant de changer ce qui s'y prête vraiment. Par exemple, refactoriser la vue pour consulter un membre (API v0.0), lister un membre (API v0.1) et d'autres comme la gestion du POST et du PUT.

Alors qu'est ce que nous avons fais dans ce sens ?

1. Nous avons refactorisé la vue pour lister les membres via les vues du site et l'API.
2. Nous avons refactorisé la vue pour consulter un membre via les vues du site et l'API.

L'utilisation de l'API (puisque c'est ce qui nous intéresse ici) se fait de la manière suivante pour ces deux cas :

• Pour lister les membres : http://127.0.0.1:8000/api/membres/
• Pour consulter un membre : http://127.0.0.1:8000/api/membres/:id

Résultat de la consultation d'un membre :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
    "id": 1, 
    "username": "admin", 
    "show_email": false, 
    "email": "", 
    "is_active": true, 
    "site": "", 
    "avatar_url": null, 
    "biography": "", 
    "sign": "", 
    "email_for_answer": false, 
    "last_visit": "2014-12-04T00:22:06.714", 
    "date_joined": "2014-12-02T21:43:52.887"
}

Note : Vous remarquez certainement que les URLs ne correspondent pas parfaitement aux URLs définies dans la ZEP. C'est sans doute temporaire pour me permettre de me concentrer sur des problématiques plus importantes que ce genre de détail.

Pour la consultation d'un membre donné, la PR est en cours de révision sur le dépôt de gustavi mais devrait bientôt être mergé (quand il a le temps puisqu'il n'en dispose pas beaucoup pour le moment). J'en profite pour vous rappeler que nous sommes ouvert à toutes contributions de développeurs externes.

Dans les prochains jours, je compte me pencher sur l'authentification OAuth2. Ce que je pense être le plus gros morceau de la ZEP.

<3

Top !! Allez courage !

Sans aucun doute, oui (mais c'est aussi la brique essentielle et réutilisable partout ailleurs après, donc le jeu en vaut la chandelle !)

<3

Comme l'a dit Andr0 je suis pas super dispo les 10 jours qui arrivent. Excellent travail comme je te l'ai déjà dit ! Pendant que tu bosses sur l'auth, je vais continuer le refactoring suivant le modèle CBV qui est quand même beaucoup plus agréable !

2 petites questions que je me pose :

• est-il judicieux de montrer les membres qui n'ont pas encore activer leur profil ?
• faut-il laisser l'accès au profil des bots ?

est-il judicieux de montrer les membres qui n'ont pas encore activer leur profil ?

Tu ne peux pas mettre un champs dans la réponse pour l'indiquer ? A charge du client de les afficher ou non. L'avantage est que du coup l'API pourrat être utilisé pour faire des stats comme, ici, le % de membres non activés.

faut-il laisser l'accès au profil des bots ?

J'ai envie de dire, idem si c'est possible.

Plop,

J'ai enfin réussi à dégager du temps pour ZdS. Je compte écrire un bon gros tuto mais j'aimerais m'investir dans le développement aussi. Du coup je pense essayer de vous donner un coup de main sur l'API. Non seulement le sujet m'intéresse mais en plus c'est le gros dev idéal pour traverser un peu tout le code.

Je vais gentiment explorer un peu tout dans les prochains jours puis j'essayerai de m'y mettre

Taguan si tu veux je peux te rajouter à notre conversation avec Andr0 pour l'API et je serai ravis de t'aider concernant le dev back (Django principalement).

@Taguan : Tu es plus que la bienvenue ! Comme le dit gustavi, nous pouvons te rajouter à la discussion privée et te débriffer un peu sur la situation.

Ah oui, avec plaisir

Mais vous attendez pas à une PR de la mort d'ici 2 jours hein, API je connais, mais Django pas du tout. Pis j'ai jamais fait de PR de ma vie non plus

<3

Biiiiien… la PR sur l'authentification OAuth 2 est faite. La simplicité dans sa mise en place est déconcertante. J'ai beau testé, ça correspond parfaitement à ce que nous avons imaginé. Il y a bien qu'une seule ligne de code à mettre et de la configuration …

Voici un exemple du résultat de la requête pour récupérer ses tokens d'authentification :

Il y a bien qu'une seule ligne de code à mettre et de la configuration …

Django power !

P*tain j'aime <3

Question (peut-être que ca a été discuté, mais je retrouve plus):

Normalement, quand une appli redemande des crédentials pour un utilisateur, le serveur ne renvoie pas le refresh_token… Il est donné que la premiere fois, et s'il est perdu, l'ancien token doit être révoqué, puis l'utilisateur doit être ré-authentifier… C'est le cas/c'est prévu ? C'est pas hyper-grave si c'est pas le cas, mais bon…

Sinon, par rapport à l'authentification

J'en avais parlé à la fin de mon dernier message. Je ne suis pas sûr qu'il soit judicieux de faire passer le login/mot de passe dans l'appli. Je voulais savoir si c'était envisageable de proposer un login à base d'une vue web.

En gros, ce que l'appli devrait faire:

• Générer une URL d'authentification, avec en paramètre son client_id, l'url de callback, et éventuellement le scope, si cette notion arrive un jour dans l'API. On peut se baser par exemple sur ce que fait Google (https://zestedesavoir.com/oauth2/auth?client_id=[...]&callback=[...])
• L'utilisateur accède dans une vue au formulaire d'authentification. Si l'utilisateur est déjà connecté (c'est le cas par exemple dans un navigateur), il y a un prompt résumant à quoi aurait accès l'application, le nom, l'auteur et une description de l'application. En dessous, un bouton accepter, et un refuser. S'il n'est pas connecté, il faut un formulaire avec Login/mot de passe, avec les même informations sur l'application.
• Si l'authentification se passe correctement, le site redirige vers l'url de callback, avec en paramètre un code d'authentification (genre http://mon-site.fr/callback?code=[code], ou, s'il s'agit d'une appli native, mon-appli://callback?code=[code] ; à noter qu'en général, les urls de callback sont fixés avant par le développer pour son appli, afin d'éviter que le callback soit utilisé vers un autre site). C'est également vers cette url, avec d'autres paramètre que l'utilisateur sera redirigé en cas d'erreur/de refus
• Ce code est récupéré par l'appli, et échangé contre des tokens, en donnant également son client_secret. (requête POST interne à l'appli vers https://zestedesavoir.com/oauth2/access_token, avec le client_secret, le code, et grant_type=code dans le form-data de la requête)

Ce flow évite de donner le mot de passe à l'appli, permet d'afficher à l'utilisateur quelques informations sur ce que permet cette autorisation, et permet de montrer qu'on est bien sur ZesteDeSavoir, et que c'est pas juste une appli qui va récupérer son login/mot de passe pour l'utiliser plus tard…

J'aimerais savoir si c'est envisageable de mettre ça en place. Même si c'est pas pour tout de suite! Le login par user/pass ne me pose pas tellement problème, il faut juste se dire que si un jour on a beaucoup d'utilisateurs, et donc des développeurs de l'API, permettre le login par user/pass pour une API, c'est juste pas sérieux! Il suffit que l'appli/le site en question soit pas en HTTPS, et le mot de passe est interceptable, parce que tout passera en clair (il est évident pour moi que l'authentification par vue web se fait en HTTPS )

Voila, désolé de pas avoir réagit plus tôt, j'étais un peu débordé ces derniers temps, mais la ça devrait aller mieux

En tout cas, c'est du beau boulot, ça avance, c'est cool!

Sandhose

Normalement, quand une appli redemande des crédentials pour un utilisateur, le serveur ne renvoie pas le refresh_token… Il est donné que la premiere fois, et s'il est perdu, l'ancien token doit être révoqué, puis l'utilisateur doit être ré-authentifier… C'est le cas/c'est prévu ? C'est pas hyper-grave si c'est pas le cas, mais bon…

C'est tout à fait ça. La requête que j'expose au dessus ne doit être fait qu'une fois pour récupérer les tokens. Après, il suffit d'utiliser le token d'authentification dans toutes les requêtes. Si le token est perdu, tu dois refaire une requête pour accéder aux tokens mais il te renverra un nouveau token (et révoquera le précédent).

Ce flow évite de donner le mot de passe à l'appli, permet d'afficher à l'utilisateur quelques informations sur ce que permet cette autorisation, et permet de montrer qu'on est bien sur ZesteDeSavoir, et que c'est pas juste une appli qui va récupérer son login/mot de passe pour l'utiliser plus tard…

J'aimerais savoir si c'est envisageable de mettre ça en place. Même si c'est pas pour tout de suite! Le login par user/pass ne me pose pas tellement problème, il faut juste se dire que si un jour on a beaucoup d'utilisateurs, et donc des développeurs de l'API, permettre le login par user/pass pour une API, c'est juste pas sérieux! Il suffit que l'appli/le site en question soit pas en HTTPS, et le mot de passe est interceptable, parce que tout passera en clair (il est évident pour moi que l'authentification par vue web se fait en HTTPS )

Tu abordes ce flow un peu tard mais il est très intéressant. Alors déjà, l'authentification OAuth 2 nécessite (en production) de faire ses requêtes en HTTPS, sinon tu ne peux rien faire. Ce point règle déjà tes craintes dans l'hypothèse où un méchant monsieur snif ton réseau pour récupérer ton mot de passe hyper important de Zeste de Savoir (troll inside mais faut pas faire attention).

Mais je ne suis pas contre faire évoluer l'authentification. L'implémentation est complètement indépendante de toutes les requêtes. Je pense donc qu'il vaut mieux garder une authentification OAuth 2 qui fonctionne hyper bien dans un premier temps pour le faire évoluer dans le futur si nécessaire.

Voilà, voilà.

Sinon, pour la ZEP, c'est un peu au point mort pour l'instant. gustavi est fort occupé et je ne parviens pas à avoir quelque chose de convenable dans le refactoring des vues.

Les fêtes approchants, nous avons travaillé un peu au ralenti mais nous avons quand même bossé sur la ZEP. Deux choses importantes sont arrivées :

1. Taguan a rejoint les rangs et sa première PR a été acceptée. Et quelle PR pour une première contribution au développement de Zeste de Savoir ! Elle a modifiées toutes les méthodes d'édition vers l'approche CBV. Vraiment, bravo à elle parce que c'est du super boulot !

2. Cela a permit de mettre en oeuvre la gestion du PUT dans l'API sur un membre donné via cette PR que j'ai terminé cette nuit et qui devrait être très prochainement mergé dans le repository de gustavi.

Alors, où en sommes-nous ? Et bien, l'un dans l'autre, nous touchons doucement au terme de la ZEP ! Il nous reste quelques petites choses :

• Nettoyer un peu le code pour éviter les quelques répétitions de code, notamment sur les conditions de validation d'un objet donné.
• La pagination mais un mécanisme intégré dans Django Rest Framework devrait proposer cette fonctionnalité en quelques lignes (voire une seule).
• Les options personnalisées dans les en-têtes, cela doit être le plus gros morceau restant puisqu'il est possible que Django Rest Framework ne supporte pas toutes les options que nous avons définis.
• Hors scope mais un souhait que nous avons, proposer l'API du staff sur les membres.

C'est tout pour le compte-rendu, j'ai quand même bon espoir d'un merge dans les semaines à venir.

Salut,

Je vais faire un mini compte rendu mais surtout un appel à de nouveaux contributeurs !

Je commence enfin à bien comprendre comment fonctionne Django Rest Framework et l'approche CBV alors j'avance bien plus vite. Et ça, c'est vraiment top !

Donc plusieurs choses faites aujourd'hui :

1. Gestion du PUT supportée pour modifier un utilisateur : https://github.com/gustavi/zds-site/pull/12
2. Centralisation des conditions de validation dans les formulaires et les serializers : https://github.com/gustavi/zds-site/pull/14
3. Et j'ai déjà une version fonctionnelle de la gestion du POST en local (création d'un compte). Voici un exemple de sortie lorsque vous allez créer un compte par l'API :

1
2
3
4
5
6

{
    "id": 13,
    "username": "user6",
    "email": "email6@email.com",
    "password": "pbkdf2_sha256$12000$Yp4hTQ4cyVJl$7Ma4sFLNdkNVF8f+rZ6ONdhwmuraNSTKoXJFV/lMVaM="
}

Voilà pour le compte rendu. Maintenant, plus intéressant, mon appel à de nouveaux contributeurs. Ce n'est clairement pas une nécessité puisque je pourrais me charger des tâches restantes mais, actuellement, je suis le seul du projet réellement compétent dans l'élaboration de l'API. gustavi donne plutôt un avis technique sur mon code et Taguan a contribué sur l'approche CBV des vues du site et pas de l'API.

J'aimerais éviter le problème que nous rencontrons avec le support du Markdown sur le site dont l'expertise est détenue exclusivement par Kje, par exemple. Je compte me charger prochainement de la création d'un compte, de la pagination et des options dans le header des requêtes HTTP mais je recherche quelqu'un qui aimerait monter en compétence dans l'élaboration d'une API Django avec la confection de l'API staff sur le module des membres ! Si vous êtes intéressé, n'hésitez surtout pas. Malheureusement, gustavi dispose de très peu de temps (juste assez pour faire de la revue de code) et Taguan n'a pas de temps pour le moment.

Sur ce, bonne nuit parce qu'il est tard à l'heure où j'écris ces lignes.