Problème avec CORS

[firm1]

Hello,

J'ai essayé d'utiliser l'API, mais j'ai un problème.

Ça, sa marche :

$ curl -i https://zestedesavoir.com/api/membres/

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 11 May 2015 19:05:14 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
ETag: "d8f9437e4f88b4e6e2ad0a6d770d970bfdd5bbbc689cc3b3390759d06d4f105a"
Vary: Accept, Cookie
Allow: GET, POST, HEAD, OPTIONS
P3P: CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"
Strict-Transport-Security: max-age=500
Access-Control-Allow-Origin: *
X-Clacks-Overhead: GNU Terry Pratchett

{"count":2480,"next":"http://zestedesavoir.com/api/membres/?page=2","previous":null,"results":[Tableau long ...]}

Mais quand je le met dans une page web :

$.get("https://zestedesavoir.com/api/membres/"); // jQuery évidemment ^^.

J'obtient ça :

Et j'ai aucune idée de l'origine de l'erreur.

Quelqu'un sait pourquoi j'ai deux Access-Control-Allow-Origin dans la réponse ?
Source:Umbra

Le fait que l'on retrouve l'url 127.0.0.1:8000 dans le message d'erreur me fait penser qu'on a ici un problème d'infra.

[Eskimon]

ping @GerardPaligot :)

[GerardPaligot]

Comme le dit @firm1, c'est sans doute un problème d'infra. Ca fonctionnait et maintenant ça fonctionne plus sans modification sur l'API.

[SpaceFox]

@Ge0 c'est pas un effet de bord de tes modifs de l'autre jour ? (sur l'IPv6)

[Eskimon]

On a des soucis sur le site lui-meme : https://zestedesavoir.com/forums/sujet/3166/de-la-physique-quantique-sur-zds/

[firm1]

Le problème persiste et rend inutilisable l'api via du javascript pour faire une webapp externe au site.

[Eskimon]

Il me semble pourtant que j'avais réussi a faire des requêtes depuis jsfiddle a une époque...

[GerardPaligot]

Vu les commentaires sur le forum, le bug me semble confirmé mais je n'arrive pas à savoir si c'est l'application qui est en faute ou l'infra. N'y connaissant rien dans ce domaine, je laisse à d'autres régler ce souci.

[DevHugo]

Cette documentation est t-elle à jours ? car pas besoin de add_header Access-Control-Allow-Origin *;. La librairie le fait déjà. ce qui pourrait créé le souci, quelqu'un veut bien aller voir la configuration sur la prod ou préprod ? (Vu qu'on à le même souci en préprod !)

[aesteve]

En local (sans nginx etc.) ça donne quoi ? Ça fonctionne bien ? (i.e. y'a qu'une seule étoile)

@DevHugo faut se méfier, le header pourrait potentiellement servir à d'autres ressources que l'API (même si je vois pas trop quoi). Le virer dans la config nginx c'est potentiellement introduire une énorme régression.

[DevHugo]

Ça fonctionne et je vais même aller plus loin, si tu teste avec une instance comme celle de Sandhose, ça marche donc c'est bien de l'infra.

@DevHugo faut se méfier, le header pourrait potentiellement servir à d'autres ressources que l'API
(même si je vois pas trop quoi). Le virer dans la config nginx c'est potentiellement introduire une
énorme régression.

Je mesure pas le danger d'effectuer cette action donc je te crois sur parole.

[aesteve]

Je mesure pas le danger d'effectuer cette action

Je dirais :

S'il y a d'autres API sur le serveur (supervision ? administration ?) auxquelles on accède par une interface web (hébergée ailleurs : => CORS)

Je vois que ça mais j'peux louper un truc.

Mais NB : y'a une autre issue qui dit que le CORS middleware pose un problème, la solution simple qui règle les deux soucis c'est de garder le CORS dans la config nginx et de la virer de la config Django.

[gustavi]

Comme dit dans le dernier meeting, ça sera fixé lors de la mise en prod de la v17.

[GerardPaligot]

Je rajoute cette issue dans la PR de Django 1.8.

[Situphen]

On laisse ouvert jusqu'à la mise en production de la v17 ?