Impossible de manipuler l'API de ZDS en Javascript

Bonjour,

J'ai un problème pour manipuler l'API de ZdS en Javascript (avec la lib jQuery).

J'ai réduit mon problème à un cas simple qui est le code suivant :

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

$('#sub').click(function(event) {
  $.ajax({
      url: "https://zestedesavoir.com/api/mps/",
      type: "GET",
      beforeSend: function(xhr) {
        xhr.setRequestHeader("Authorization", "Bearer <mon_token>");
      },
      success: function(data){
        $('#result').empty().append(data);
      }
    });
});

Dans ma console JS j'ai le message suivant lorsque je clique sur le bouton prévu sub.

1

13:10:00.453 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://zestedesavoir.com/api/mps/. (Reason: CORS header 'Access-Control-Allow-Origin' does not match '*, *').1 <unknown>

PS : je précise que je lance mon navigateur en mode non-connecté à ZdS pour ne pas avoir de conflit d'authentification avec mes cookies.

Est-ce un bug ou est-ce que je fais mal mon appel ?

Bonjour firm1,

Je pense qu'il faut utiliser une instance de XDomainRequest mais je ne sais pas si c'est aisé ou automatique de faire ça en jQuery.

Autre piste que je ne connais pas du tout : https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

Je pense qu'il s'agit en effet d'un problème de refus de la part de ton navigateur et/ou de ton serveur que de céder à une requête inter-origines. Ce qui peut être lié à un défaut de sécurité si je décidais de te faire exécuter du code à destination de zestedesavoir alors que celui-ci est délivré depuis mon propre domaine, si tu vois ce que je veux dire…

Quelqu'un a d'autres idées ?

Tu peux regarder dans Chrome quels headers HTTP contient ta requête, et quels headers te sont renvoyés par le serveur stp ?

Ca ressemble à un bug côté serveur qui renvoie *, * dans le header Content-Access-Allow-Origin qui est un pattern bizarroïde, mais comme ça ne se produit pas dans un cas simple (un simple appel GET vers cette URL depuis le browser ne reproduit pas le soucis), je pense que tu passes par un truc bizarre qui trifouille le header.

Le truc bizarre en question pouvant être un proxy, du code côté serveur, un reverse proxy, bref un peu tout et n'importe quoi.

Quand tu fais la requête depuis ton browser, bêtement, ça donne quoi ?

Lorsque je fais la requête depuis le browser en mode connecté (au site), j'ai bien mon json qui est retourné. En mode déconnecté (au site), il me dit que je dois me connecter. Mais ça me semble normal car mon navigateur (firefox) tout comme mon curl semble passer outre les problématique de CORS.

C'est bien le problème. Mais le souci me semble fortement être lié au serveur puisqu'il ne semble pas renvoyer les bonnes entêtes.

Je te file ça quand je ne serais hors d'un proxy (@home). En attendant, vous pouvez faire des essais via ce jsfiddle en cliquant sur test.

Ouep c'est bien ça. La réponse contient *, * comme header Access-Control-Allow-Origin.

Firefox l'affiche tel quel, Chrome considère que c'est une liste d'origines et affiche plusieurs lignes.

Hypothèse1 : Django renvoie un header via le middleware CORSbidule, puis nginx intercepte la requête et en rajoute un supplémentaire.

Hypothèse2 : dans la config du middleWare, il y a deux appels du style : allowedOrigins.add('*')

Hypothèse3 : en plus du middleware, la réponse HTTP est interceptée et modifiée méchamment. (ça me semble peu probable dans le cas d'une application aussi "haut niveau" que ZdS)

L'hypothèse 1 me semble fort probable mais m'étonne beaucoup. Quand on regarde la conf nginx (auquel je ne connais fichtre rien), y'a addHeader et pas addValueToHeader, donc autant il écraserait la valeur fixée par Django je comprendrais, autant concaténer ça me paraît curieux.

Je pencherais pour l'hypothèse 1. ça ou une mauvaise redirection http/https qui fait rajouter un second header.

Bon dans tous les cas, le problème me semble avéré. Je vais créer l'issue qui va bien le ticket existe déjà en fait.

Si tu remplace par l'api de beta, ça ne marche pas non plus ! Soit on à la même configuration foireuse en préproduction, soit c'est un souci dans le code.

A vue de nez je vois pas ce qui pourrait merder dans le code. Ni en inspectant la requête envoyée d'ailleurs

Mais j'peux avoir loupé un truc.

En preprod c'est pire, l'API des mps est carrément filtré par IP pour que tout le monde ne joue pas avec quand elle était en beta…