J'ai de nouvelles questions :
PATCH sur les membres, c'est quoi le but ?
La doc list une méthode PATCH sur les membres, c'est quoi le but ?
PATCH est une mise à jour partielle d'une ressource donnée (ici les membres). Normalement, il n'est pas censé figuré dans la liste Swagger. C'est un bug dans Swagger. J'ai l'issue dans le projet Swagger, si tu es intéressé par ça, je pourrais te la linker quand j'aurais un ordinateur à disposition.
On peut bannir ou mettre en lecture seule, et les enlever. Mais on a aucun moyen de savoir si un membre a une sanction d'appliqué. Elle doit manquer dans les infos sur un membre, non ?
Pour faire simple, une sanction n'est pas disponible directement dans le modèle du Profile. Il s'agit d'une autre classe, dans un autre module. Il s'agit donc d'une autre ressource. Etant donné que cette classe n'est pas encore disponible via l'API, il n'est en effet pas possible de l'afficher dans l'API des membres. Pour l'instant.
Merci !
Un autre truc, quand on met un jour un membre on peut spécifier deux champs qui ne sont pas fournit par le get classique : hover_or_click et show_sign. Est ce normal ?
Un autre truc, quand on met un jour un membre on peut spécifier deux champs qui ne sont pas fournit par le get classique : hover_or_click et show_sign. Est ce normal ?
C'est un oubli de ma part. Je vais le rajouter.
PS : Sorry, j'ai eu un week-end assez chargé. Je dispose maintenant d'un ordinateur et ce soir viendra quelques PRs sur ce qui a été discuté aujourd'hui, sur GitHub et dans ma petite tête. 
Edit : L'issue de Swagger pour les méthodes est disponible ici.
Bien, plusieurs choses hier soir :
Sachant quand même que CORS ne fonctionnait pas en local. Théoriquement (tout comme c'était le cas pour le throttling) et par rapport à la documentation, cela devrait fonctionner mais j'ai du manqué quelque chose pour savoir le tester. Si vous avez un environnement de développement ZdS sous la main, que vous connaissez le principe de CORS et que vous avez un peu de temps urgemment (la deadline approche à très grand pas), n'hésitez pas à faire la QA de la PR.
Pour le CORS, je me demande s'ils n'est pas obligatoire que la requête émanant du client possède un header Origin. Si ce n'est pas le cas c'est possible que la lib ne rajoute pas les headers à la réponse http en considérant que comme l'origine n'est pas connue ce n'est pas du CORS. Ça peut être un test simple à faire.
En fait, j'ai testé avec une console REST (plus précisément, la web app Postman) qui m'a jamais posé problème en local ou en bêta. J'en ai donc conclu que ce n'était pas la bonne manière de tester la fonctionnalité.
Du coup, quelle est cet header Origin ? Que dois-je renseigner comme valeur pour être sujet à l'application du CORS ?
Je me réfère juste à la spec' CORS du W3C.
Server-side applications are enabled to discover that an HTTP request was deemed a cross-origin request by the user agent, through the Origin header.
Du coup, tu peux utiliser n'importe quel hostname qui ne soit pas celui sur lequel ton serveur tourne (donc pas localhost).
Essaie : Origin: http://google.com par exemple.
E.g. : si j'ouvre Chrome sur lemonde, onglet "Network", puis filtre (petite icone d'entonnoir) sur XHR :
On voit plein de requêtes dont :
1 2 3 4 | Remote Address:93.184.220.20:80 Request URL:http://www.lemonde.fr/ws/1/ticker/alerte/ Request Method:GET Status Code:304 Not Modified |
Si je regarde les headers de cette requête je vois des Cookies, un Referer, Accept, les directives de cache etc. mais pas d'origin. Normal, c'est le même domaine que celui sur lequel j'ai chargé la page.
Ensuite, si je regarde une autre requête :
1 2 3 4 | Remote Address:209.177.145.68:80 Request URL:http://rpt.cedexis.com/n1/(blahblablah je coupe) Request Method:GET Status Code:200 OK |
C'est une requête sur un autre domaine. Et dans les headers on voit bien :
1 | Origin:http://www.lemonde.fr |
En JS les libs (ou même l'object XHR lui-même si je me rappelle bien) s'en occupent seuls. Evidemment avec un client tel que Postman ou un client lourd, il faut positionner ce header à la main.
firm1 a eu la gentillesse d'installer la branche sur un VPS (lien disponible sur ce message GitHub) et je tente donc la requête suivante dans ma console REST : http://vps137741.ovh.net/api/membres/ avec un header Origin: http://google.com.
Lorsque j'inspecte la requête, la requête ne semble pas tenir compte de cet header :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | Remote Address:37.187.47.249:80 Request URL:http://vps137741.ovh.net/api/membres/ Request Method:GET Status Code:200 OK Request Headers Accept:*/* Accept-Encoding:gzip, deflate, sdch Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4 Cache-Control:no-cache Connection:keep-alive Cookie:hasconsent=true Host:vps137741.ovh.net User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Response Headers Allow:GET, POST, HEAD, OPTIONS Connection:keep-alive Content-Type:application/json Date:Tue, 24 Feb 2015 09:24:30 GMT ETag:"d8f9437e4f88b4e6e2ad0a6d770d970bfdd5bbbc689cc3b3390759d06d4f105a" Server:nginx/1.6.2 Transfer-Encoding:chunked Vary:Accept, Cookie |
Edit :
Par contre, si je fais la même requête avec curl :
1 2 3 4 5 6 7 8 9 10 11 | curl -I -H "Origin: http://google.com" http://vps137741.ovh.net/api/membres/ HTTP/1.1 200 OK Server: nginx/1.6.2 Date: Tue, 24 Feb 2015 09:29:13 GMT Content-Type: application/json Connection: keep-alive Access-Control-Expose-Headers: etag, link Vary: Accept, Cookie ETag: "d8f9437e4f88b4e6e2ad0a6d770d970bfdd5bbbc689cc3b3390759d06d4f105a" Allow: GET, POST, HEAD, OPTIONS Access-Control-Allow-Origin: * |
Oui ça fonctionne bien avec une vraie requête XHR. Comme tu as pu le voir avec curl 
Avec quoi ça marchait pas ? Postman ?
EDIT : le test que je fais peut-être considéré comme un test de client "réel". J'ai une page web servie par Vert.x en local, qui a travers un script JS fait un appel Ajax (un simple jquery.ajax()). On est assez proche de ce que les "end-users" vont faire
Postman qui est un client REST qui ne semble pas connaitre le header Origin. Le bug est spécifique à cet outil à mon avis.
Oui oui je connais Postman, mais je ne m'en sers pas pour faire du CORS généralement. Je fais les tests directement en JS.
En fait, c'est pas un bug de l'outil je pense. Comme c'est une bête extension Chrome, j'imagine qu'elle utilise l'API Chrome pour envoyer des requêtes XHR. Et j'imagine que Chrome interdit aux extensions de trafiquer ce header… Ça semble assez logique pour éviter les saloperies.
Bien, en fin de compte, je testais avec le mauvais outil. C'est bon à savoir.
Sinon, Javier, tu viens de faire ta première QA sans le savoir. 
T'inquiètes que j'ai pas fini de l'utiliser cette API
J'ai plein d'idées de bricolages !
J'ai rien de tout fait pour gérer l'OAuth 2 sous la main là :\ C'est pas juste l'affaire de 5 minutes malheureusement.
Salut à tous,
Bien des bonnes nouvelles. Nous sommes jeudi et, officiellement, c'est aujourd'hui que SpaceFox va faire la mise en prod de la release 1.6. Alors, qu'en est-il de l'API ? Parce que officieusement, SpaceFox était prêt à accorder quelques jours si nécessaire au vu de la première intégration de l'API dans la plateforme Zeste de Savoir.
Et bien l'API n'a pas besoin de ces quelques jours puisqu'elle est dorénavant fonctionnelle. Tous les bugs remontés (code ou infra) ont été résolus dans le délai des 2 semaines de tests d'une release et elle correspond en très grande partie à la spec décrite dans le premier message de ce sujet.
Pour rappel, les dernières fonctionnalités/bugs corrigés au sujet de l'API :
api/membres/mon_profil pour récupérer ses infos sans l'identifiant de son profilEncore merci à vous tous d'avoir contribué à cette ZEP. En espérant que la mise en production se passe bien.
Quid de l'inscription via l'API qui pouvait être spammée ? On est d'accord que c'est réglée via la limitation du throttling c'est ca ? (donc on peut toujours la spammer mais dans une moindre mesure)
En tout cas chapeau encore pour le boulot et la réactivité !
Ouaip, il n'est plus possible de créer 60 000 utilisateurs grâce au throttling.
Quid de l'inscription via l'API qui pouvait être spammée ? On est d'accord que c'est réglée via la limitation du throttling c'est ca ?
J'avoue que c'est le dernier point qui me fait un peu peur aussi. Ce n'est pas rassurant (throttling compris) de savoir que n'importe qui peut créer des utilisateurs sans aucune forme d'authentification à l'API. Et je ne sais pas dire si le Throttling a été testé sur autre chose que des requêtes de types GET.
N'est-il pas possible de rajouter la contrainte "pour faire une inscription, l'utilisateur doit disposer d'une clé API" ? ça évitera de vivre dans la peur qu'un petit malin s'amuse à faire ses 60 créations depuis l'IP d'une université/entreprise par exemple (qu'on ne pourra logiquement jamais bannir).
Ce message est sponsorisé par le ministère de la protection des bisounours
Et je ne sais pas dire si le Throttling a été testé sur autre chose que des requêtes de types GET.
Pour avoir essayer de passer outre a cause du problème de double authentification sur la beta, je pense qu'il marche bien.
Pour le reste je ne suis pas surs que la clé API soit bien sécurisante mais bon.
Pour le reste je ne suis pas surs que la clé API soit bien sécurisante mais bon.
ça permet déjà de limiter ce genre d'actions a un périmètre limité de personnes. On me dira aussi que de toute façon les clés peuvent être récupérées par n'importe qui, mais au moins on saura les désactivés plus facilement/proprement.
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