ZEP-17 : Elaboration de l'API des membres

Bon puisque tout le monde semble d'accord pour dire que les tests déjà présent sont pas mal, ne peut on pas partir là dessus ? Et quand on aura quelques lib clients pour communiquer avec l'API, il sera toujours temps d'en rajouter en utilisant la lib en question, non ?

la syntaxe de ce genre d'outils

Est-ce-que tu peux faire une phrase plus vague stp ?

Y'a 50 000 variantes de DSL, on en a déjà parlé, et ça me gonfle de lire ce genre de débilités non argumentées. Tu l'arrêtes où "ce genre d'outils" parce que la syntaxe à base de given, where, then, expect me paraît être de très loin la plus adaptée à l'écriture de ce genre de tests, et je maintiens, faut vraiment vraiment ne jamais avoir travaillé avec de bonnes DSL pour mettre tous les outils dans le même panier et manquer énormément de discernement.

Bref, là n'est pas la question. L'important c'est que l'API soit testée et ça a l'air d'être le cas, si un jour un client HTTP indépendant manque (pour une des raisons citées plus haut ou une autre) il sera toujours temps de le rajouter.

J'ai déjà argumenté à ce sujet. Je parle de la syntaxe type "on fait des phrases", pas des DSL en eux-mêmes ! Et le "ce genre d'outils" ne s'appliquait qu'à ceux cités dans le message de firm1 qui utilisent la syntaxe décrite par firm1.

Et, sérieusement, j'en ai ma claque des fanboys qui surinterprètent tout et n'importe quoi dès qu'on ose critiquer la syntaxe "langage naturel". Je n'ai jamais étendu ma réflexion à tous les DSL ! Mais non, on ne peut pas dire qu'on aime pas ce genre de syntaxe sans se faire incendier !

PS : oui, je sais mon message était lapidaire et flou. Mais ça n'excuse pas la sur-interprétation à ce point, les termes du genre "débilités", "manquer énormément de discernement", etc. Surtout qu'on en a déjà parlé et que tu sais que je ne considère pas tous les DSL comme identiques.

Comment on peut deviner à quoi s'applique "ce genre d'outils" c'est bien là tout l'objet de ma remarque.

Et pour le côté fanboy je te laisse à ton procès d'intention va.

Comment on peut deviner à quoi s'applique "ce genre d'outils" c'est bien là tout l'objet de ma remarque.

Si tu ne sais pas, pose la question. N'interprète pas.

Pour le côté fanboy, tu n'es pas visé personnellement. C'est une analyse générale : la plupart des défenseurs de DSL que je connais semblent persuadés que seul le "langage naturel" est valable.

L'égout et les couleuvres … en même temps la cible ici n'est pas le développeur.

Pouvons-nous conclure que les tests actuels suffisent et que nous optons pour une QA normale (comme pour toutes les autres ZEP) ?

Je pense que OUI. Mettez un gros "en beta" sur la doc de l'API, rappelez le dans la news qui sortira pour la version rajoutant cette API, voir utilisé un sous domaine "beta" à la place de la version tant que la version complete et versionné n'est pas finit, et voila. Continuons. Le mieux est l'ennemie du bien. Actuellement c'est déjà pas mal testé avec les outils de tests intégré à DRF, ça suffira largement pour la période de beta.

D'accord avec Kje

Je tiens à m'excuser pour le coup de gueule de tout à l'heure. Le post qu'il ne fallait pas au moment où il ne fallait pas m'a fait m'emporter pour rien.

Sinon pour parler d'autre chose.

Les emails

Je me suis posé quelques questions concernant les adresses emails. N'ayant pas les moyens de tester la branche de PR il se peut que ça déjà été fait, donc je m'en excuse d'avance si c'est le cas, mais je ne la vois pas dans la spec.

Alors il s'agit des email. Aujourd'hui sur le site j'ai coché la case "afficher son email publiquement" car je sais qu'elle n'est visible que par les membres du site et que même en tant que membre inscrit elle est obfusquée pour les bots. Donc je suis rassuré du fait qu'un robot ne puisse pas via un simple script scanner les adresses mails des membres.

Ma question est donc de savoir si l'API me préserve toujours de cette sécurité. En gros la spec ne me dit pas exactement si mon adresse email est assez couverte.

Les groupes

Là aussi, je pensais suite a une de mes remarques que la spec avait été mise à jour sur ce point, mais on dirait que ce n'est pas le cas (ou du moins c'est pas clair). Je me cite :

Est-ce qu'on renvoi toujours le fameux is_staff dans le retour json ? Comment sont gérés les comptes particulier du type bot, etc.

E-mails : ils ne sont jamais affichés quand tu demandes la liste des utilisateurs et, quand tu demandes un utilisateur précis, il sera affiché uniquement si l'utilisateur l'accepte (autrement dit, si show_email est à True).

Groupes : Nous renvoyons toujours is_staff. Je complète ma PR ce soir en enlevant cette information.

OK.

/me s'en va cocher l'option pour ne plus afficher son adresse mail

Je ne vois pas bien la différence entre avant et après l'API. Si tu voulais cacher ton e-mail, tu aurais du le faire bien avant.

Bah avec l'API, un bot pourra lancer une requete pour recupérer tous les membres, et pur chaque membre demander les details.

Tout ceux qui ont activés cette fonctionnalité peuvent se retrouver spammés. Alors qu'avant l'API ce n'est pas possible pour un bot.

C'est pas faux. J'ai regardé un peu d'autres API (comme celle de GitHub) et aucune protection particulière semble être mise en oeuvre à ce sujet. Je ne vois pas bien comment nous pourrions palier à ce "problème" (si s'en est vraiment un).

ne pas donner de compte développeur aux bots?

Qu'est ce que tu entends par "compte développeur" ? Du client pour l'authentification ? Récupérer la liste des membres et les informations sur un membre ne nécessitent pas une requête authentifiée.

Aujourd'hui le site n'affiche pas email (quelque soit le cas) à quelqu'un qui n'est pas membre.

Intéressant, je vais voir ce que je peux faire dans ce sens alors. Rajouté dans ma ToDo.

Ne fournir le mail que si le membre est authentifié, pourquoi pas. Mais en soit ça reste une protection faible.

Ça évitera cependant que les mails se retrouvent en clair en copiant-collant une url dans son navigateur.