J'ai mis en place le partage de ressources d'origine multiple sur un serveur (Jetty à l'aide de CrossOriginFilter) et cela fonctionne parfaitement sur IE8 et Firefox. Sur Chrome, c'est tout simplement ... non.
$.ajax({ url : crossOriginURL,
type : "GET",
error : function(req, message) {
alert(message);
},
dataType : "json" } );
La fonction d'erreur est appelée, avec le message utile "erreur". Il semble que ce soit la demande, mais sans les en-têtes auxquels vous vous attendez. Si l'URL provient de la même origine, cela fonctionne bien.
ce qui a finalement fonctionné pour moi est xhr.setRequestHeader('Content-Type', 'text/plain');
J'ai résolu mon problème de cette façon:
Ajoutez ceci à votre code PHP:
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Credentials: true ");
header("Access-Control-Allow-Methods: OPTIONS, GET, POST");
header("Access-Control-Allow-Headers: Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control");
Ou ajoutez ces en-têtes à votre réponse.
Problème: les navigateurs demandent au serveur des options avant votre requête principale, afin de vérifier si le site a la possibilité d’autoriser la communication avec une origine différente, puis, dans l’affirmative, ils effectuent votre demande POST ou GET.
EDIT: Essayez ceci (sans votre bidouillage) pour voir si vous recevez des données ...
$.ajax({ url : crossOriginURL,
type : "GET",
error : function(req, message) {
alert(message);
},
success : function(data) {
alert(data);
},
dataType : "text"} );
Il semble que l’affiche originale ait peut-être résolu le problème, mais pour quiconque ayant le même problème que le commentateur Elisabeth, je pense que le problème peut être que Chrome refuse de définir un en-tête Origin pour une demande CORS si vous exécutez la demande à partir d’un fichier. fichier local. Il ne vous laissera même pas explicitement remplacer l'en-tête Origin. Le serveur voit alors "Origine: null", ce qui donne 403 dans la plupart des cas. Firefox n’a apparemment pas cette contrainte, comme je l’ai découvert après de nombreuses tentatives d’arracher les cheveux.
Si vous devez absolument utiliser Chrome dans ce cas, vous pouvez résoudre votre problème en exécutant un serveur Web localement et en accédant toujours à votre fichier via http: au lieu de fichier :.
Dans mon cas, c'est localhost: 8001 (le client) qui essaie d'appeler les API sur localhost: 7001 (sur server.js en tant que serveur de nœud). Même si j'avais installé et activé le plug-in CORS sous Chrome, la stratégie CORS les avait néanmoins rejetées en tant que contrôles en amont.
Il m'a fallu plus d'une demi-journée pour enfin résoudre le problème… Voici les étapes «stupides», croyez-le ou non:
je. Désactivez le plug-in CORS, rechargez l'application, vous devriez toujours avoir les erreurs correctes.
ii. Activez-le, rechargez l'application, si les API réussissent, arrêtez-vous ici, inutile de passer à l'étape iii.
iii. Toutefois, si vous obtenez toujours le rejet de CORS, désinstallez Chrome et installez un Chrome à jour.
iv. Sur le nouveau Chrome, le plugin CORS précédemment installé devrait toujours être là, mais avec le statut OFF.
v. Rechargez la page, vous devriez obtenir sur la console les messages de rejet CORS qui sont corrects.
vi. Allumez-le de nouveau, rechargez la page, les erreurs devraient disparaître.
Aucune autre idée si les étapes ci-dessus ne fonctionnent toujours pas dans votre cas.
J'ai aussi essayé ce qui suit sur server.js (Node) et je ne fonctionne toujours pas, donc pas la peine d'essayer:
var app = express();
var cors = require('cors'); // Already done “npm i cors --save-dev”
app.options('*', cors());