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.
Kje : Tu as une protection plus robuste ? Là, nous parlons quand même de disposer d'un client OAuth2 pour faire la requête et de faire la requête en fournissant les headers nécessaires à l'authentification pour une requête qui nécessite pas forcément d'une authentification. Ca ne reste pas infaillible mais c'est pas mal je trouve.
A priori, ce qu'on peut faire de plus robuste tout en restant relativement simple, c'est que lorsque les infos sur un membre ayant accepté de fournir son adresse sont demandées par le biais de l'API, une adresse mail fictive (et aléatoire, bien sûr) @zestedesavoir.com soit créée, qui soit une simple redirection vers l'adresse réelle du membre, et qui soit supprimée au bout d'une heure1. Cela n'empêche pas d'envoyer un pourriel juste en suivant (c'est impossible), mais ça empêche la constitution et la diffusion d'une base de données d'adresses mail. Avec l'authentification en plus, cela demanderait de se donner vraiment du mal pour pouvoir spammer pendant à peine une heure. 
J'ai bien conscience que cela représenterait pas mal de boulot à mettre en œuvre, mais je pense que ce serait solide.
Pour éviter d'ouvrir une porte facile à une attaque DoS, si une adresse fictive existe déjà pour un membre, qu'elle est âgée de moins d'une heure et qu'une nouvelle requête est faite sur ce membre, on n'en crée pas une nouvelle. ↩
A priori, ce qu'on peut faire de plus robuste tout en restant relativement simple, c'est que lorsque les infos sur un membre ayant accepté de fournir son adresse sont demandées par le biais de l'API, une adresse mail fictive (et aléatoire, bien sûr) @zestedesavoir.com soit créée, qui soit une simple redirection vers l'adresse réelle du membre, et qui soit supprimée au bout d'une heure1. Cela n'empêche pas d'envoyer un pourriel juste en suivant (c'est impossible), mais ça empêche la constitution et la diffusion d'une base de données d'adresses mail. Avec l'authentification en plus, cela demanderait de se donner vraiment du mal pour pouvoir spammer pendant à peine une heure.
J'ai bien conscience que cela représenterait pas mal de boulot à mettre en œuvre, mais je pense que ce serait solide.
Je ne doute pas de l'efficacité de l'idée, mais suis je le seul a me demander pourquoi tu as commencé ton explication par "en restant relativement simple" ? 
Pour éviter d'ouvrir une porte facile à une attaque DoS, si une adresse fictive existe déjà pour un membre, qu'elle est âgée de moins d'une heure et qu'une nouvelle requête est faite sur ce membre, on n'en crée pas une nouvelle. ↩
Ha je ne dis pas ça. Perso ça me va si on oblige d'etre authentifié pour récupérer les mails. Je n'ai pas trop d'autres solutions. Mais faut être conscient que ça reste une protection faible.
Dominus : Ça représente pas mal de boulot, surtout au niveau de l'industrialisation de la création de l'adresse mail. Mais surtout, pourquoi limiter à une heure ? pourquoi pas plus ou moins ?
Pour le moment je propose qu'on se contente de ça et si on remarque des abus, on pourra, temporairement, désactiver l'affichage des mails dans l'api le temps de mettre en plus une solution plus propre.
Le fait que d'autres site ne font rien de particulier me fait penser qu'on aura jamais le problème. Autant faire ce genre de script sur github, ce serait mille fois plus rentable que le faire sur zds !
Je ne doute pas de l'efficacité de l'idée, mais suis je le seul a me demander pourquoi tu as commencé ton explication par "en restant relativement simple" ?
Parce qu'il n'y a qu'un seul mécanisme assez bateau et pas d'exception ? 
Mais surtout, pourquoi limiter à une heure ? pourquoi pas plus ou moins ?
Durée donnée au pif, ce n'est pas vraiment la question.
PS : je suis d'accord que ça n'a rien d'urgent. C'est juste une proposition à garder sous le coude si cela devient vraiment nécessaire.
NB : à noter que sur l'API Github y'a une rate-limitation.
Si tu fais un crawler qui parcourt tout plein de repos et fais une requête par utilisateur (compte-tenu du nombre de repos sur github) tu risques de vite atteindre cette rate-limitation (NB : Eskimon en avait fait les frais avec son script, la rate-limitation sur l'API publique est assez basse).
Certes si tu utilises un token d'application la limite est plus élevée, mais dans ce cas t'es obligé de faire une requête "en tant qu'app" donc Github a la connaissance de qui tu es et potentiellement retracer ce que tu fabriques avec ton token.
Ca fait quand même une grosse diff dans les deux approches. Après je ne sais pas si l'email est exposé par Github quand on récupère juste la liste des utilisateurs (et pas uniquement UN utilisateur).
PS : En attendant mieux (désolé j'avais juste 5 minutes au café) :
J'ai complété la PR suivant vos retours de la journée. Si vous en avez d'autres, n'hésitez surtout pas ! Par contre, je ne développe pas le week-end, cela attendra donc lundi pour ma part.
En attendant, vous pouvez QA la PR fonctionnement : tirer la branche de la ZEP, installer les nouvelles dépendances et tester l'API en local. C'est avec plaisir que j'accueillerais vos retours.
Bien, comme vous avez pu le remarquer avec le précédent message de gustavi, la PR liée à cette ZEP a été mergée vers la branche dev du dépôt officiel. Elle est également en phase d'être déployée sur la bêta pour pouvoir permettre à tout le monde de tester la ZEP. A ce sujet, deux bugs ont déjà été repérés. Le premier est sans doute lié à un conflit dans la configuration de swagger et du serveur de bêta. La seconde est liée au cache que nous avons appliqué à certaines routes de l'API mais la PR est déjà proposée. Si vous vous sentez l'âme de faire la première QA liée à l'API, je vous en prie !
Alors cette ZEP, c'est quoi ? Et bien, c'est avant tout une très grande réflexion autour de ce que nous pensons être une belle API REST et aux informations auxquels nous voulons (ou pas) accéder. Nous aurons fait pas moins de 7 pages sur le sujet de la ZEP 2 avant de nous rendre compte que le travail allait être trop colossal pour décider de créer cette sous ZEP avec ses 12 pages de discussion. Vous tous, la communauté, avez aidé dans la réalisation de cette ZEP par toutes ces discussions, ces débats, ces accords ou ces désaccords. Pour cela, un très grand merci à vous tous parce que c'est un premier pas vers ce qui va devenir l'une de nos killers features (d'autres ZEP sont toutes aussi intéressantes, ne l'oublions pas !).
Durant le développement, il y a eu plusieurs contributeurs. Au départ, nous étions 2 (gustavi et moi-même) et Taguan est très vite venue nous rejoindre. A 3, nous nous sommes organisé pour travailler en équipe et proposer des PRs sur le dépôt de gistavi, qui avait la gentillesse de faire de la revue de code avec la masse de travail scolaire qu'il avait. Une fois la ZEP arrivée presque à terme, nous avons sollicité l'aide de Situphen et Sandhose pour le côté front et ils ont proposé des PRs de qualité et avec plaisir à ce sujet.
Donc, malgré le fait que nous voyons souvent mon pseudo associé au développement de cette ZEP, je tiens à rappeler que c'est un travail d'équipe entre tous les contributeurs et toute la communauté de Zeste de Savoir. Chacun à apporter de son temps, de ses connaissances ou de ses capacités techniques pour faire aboutir cette ZEP. Pour tout cela, je voudrais tous vous remercier !
Je fais des tests en local et même si ça marche pour les trucs publics, je bute sur l'authentification. L'url http://localhost:8000/oauth2/access_token ou même http://localhost:8000/oauth2, indiqué dans le dernier messages détaillés, me renvoies des 404 quoique je tente. J'ai cherché dans la doc en beta et je ne trouve rien…
Es-tu certain que tu as installé la dépendance provider.oauth2 et que tu as mis à jour la base de données ? Des questions stupides mais tu es le seul à avoir des problèmes 404. Une 400, j'aurais pu comprendre mais une 404, à part ne pas avoir installé la dépendance …
Edit : Est-ce que tu vois la catégorie OAuth2 dans ton espace admin ?
J'ai les mêmes problèmes sur la pré-production en fait. J'ai des 404 dessus.
Je te contact par MP parce que j'y arrive sur la preprod moi.
D'ailleurs, comment on a une clé dans la version dev ? Je sais que dans la version de production, vous allez rajouter un bouton pour les devs et ainsi récupère la clé.
Merci encore (encore ) pour cette api
En local tu peux aller dans le panneau d'admin pour le faire. En pré-production faut demander a un admin.
Bien, quelques bugs ont été remontés suite à la mise en production sur le serveur de la bêta et ont été rapidement corrigés. Cependant, dans la nuit, un membre s'est amusé à abuser de la création d'un membre pour en créer un petit paquet et nous fait réfléchir sur la pertinence de pouvoir créer un compte via l'API. J'aimerais donc votre avis sur la situation :
Ce sont des questions assez urgentes. Si vous avez un peu de temps quand vous lisez ces lignes, n'hésitez pas à donner votre avis directement !
J'en profite pour rappeler les règles d'accès à la bêta :
En conséquence des abus de cette nuit, le mot de passe de la bêta a été changé, et l'IP du membre qui en a abusé a été bannie.
Je ne donnerai le mot de passe qu'à ceux et celles qui s'engagerons à respecter ces règles, qui me paraissaient pourtant relever de la bienséance élémentaire.
Perso je pense qu'il faut le garder avec une limitation type "limitation a N par heure". Une autre solution est de proposer une URL avec une page légère a afficher dans les app pour l'inscription. Mais je trouverais ça dommage.
Je pense que c'est même plus général que le cas de la création de membre et j'en ai déjà parlé sur d'autres topics concernant l'API, toutes les APIs disposent d'une rate limitation forte dans le cas où l'utilisateur n'est pas authentifié (une fois qu'il l'est la restriction est adoucie mais toujours présente). On ne peut pas empêcher un petit malin de faire des bêtises, pire encore : on ne peut pas non plus empêcher un client d'introduire un bug dans son app ou même ses tests (et laisser tourner un test malencontreusement, même si là ce n'était sans doute pas le cas). En aucun cas il ne faut que ça écroule la plateforme ou ait un effet de bord indésirable.
Donc pour moi il faut introduire cette notion avant le passage en prod et statuer sur les différentes valeurs de ces limitations :
Je pense qu'on peut partir sur les deux cas authentifiés / non authentifiés et être assez strict sur le cas non-authentifié. On n'a pas vraiment (encore) de nécessité de faire du polling (la liste des membres ne change pas toutes les 2 minutes). Et en théorie, la requête pour créer un compte se fait en mode non-authentifié non ? Donc le cas est couvert.
Voilà pour mes 2 cents.
Cela fait un moment que je veux rajouter un throttling à l'API. Cette fonctionnalité est intégré dans DRF. Cependant, le throttling ne parvient pas à s'appliquer parce que Zeste de Savoir utilise un cache. Je me suis un peu renseigné et cela ne semble pas possible d'appliquer un throttling avec notre implémentation actuelle du cache. Je suis en train de demander confirmation sur la mailing list de DRF.
Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte
