"Requête multi-origine bloquée" de Firefox malgré les en-têtes
J'essaie de faire une simple requête cross-Origin, et Firefox la bloque systématiquement avec cette erreur:
Demande d'origine croisée bloquée: la règle de même origine interdit la lecture de la ressource distante dans [url]. Cela peut être corrigé en déplaçant la ressource dans le même domaine ou en activant CORS. [url]
Cela fonctionne très bien dans Chrome et Safari.
Autant que je sache, j'ai défini tous les en-têtes corrects sur mon PHP pour que cela fonctionne. Voici ce que mon serveur répond avec
HTTP/1.1 200 OK
Date: Mon, 23 Jun 2014 17:15:20 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u8
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Request-Headers: X-Requested-With, accept, content-type
Vary: Accept-Encoding
Content-Length: 186
Content-Type: text/html
J'ai essayé d'utiliser Angular, jQuery et un objet XMLHTTPRequest de base, comme suit:
var data = "id=1234"
var request = new XMLHttpRequest({mozSystem: true})
request.onload = onSuccess;
request.open('GET', 'https://myurl.com' + '?' + data, true)
request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded')
request.send()
... et cela fonctionne dans tous les navigateurs sauf Firefox. Quelqu'un peut-il aider avec cela?
Il s'avère que cela n'a rien à voir avec CORS - c'était un problème avec le certificat de sécurité. Erreurs trompeuses = 4 heures de maux de tête.
J'ai constaté que mon problème était que le serveur auquel j'avais envoyé la requête croisée avait un certificat qui n'était pas approuvé.
Si vous souhaitez vous connecter à un domaine croisé avec https, vous devez d'abord ajouter une exception pour ce certificat.
Vous pouvez le faire en visitant une fois le lien bloqué et en ajoutant l’exception.
J'ai trouvé la solution après 2 jours :(.
Remarque importante: lorsque vous répondez à une demande avec des informations d'identification, le serveur doit spécifiez un domaine et ne pouvez pas utiliser de joker.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Requests_with_credentials
Juste un mot d'avertissements. J'ai enfin résolu le problème avec Firefox et CORS.
La solution pour moi était ce post
Cependant, Firefox se comportait vraiment très étrangement après avoir défini ces en-têtes sur le serveur Apache (dans le dossier .htaccess).
J'ai ajouté beaucoup de console.log("Hi FF, you are here A") etc. pour voir ce qui se passait.
Au début, on aurait dit qu'il était suspendu à xhr.send(). Mais j’ai découvert que cela n’arrivait pas à cette déclaration. J'ai placé un autre console.log juste avant et je n'y suis pas parvenu - même s'il n'y avait rien entre le dernier console.log et le nouveau. Il s'est juste arrêté entre deux console.log.
Réordonner les lignes, supprimer, pour voir s'il y avait un caractère étrange dans le fichier. Je n'ai rien trouvé.
Redémarrer Firefox a résolu le problème.
Oui, je devrais déposer un bogue. C'est juste que c'est si étrange, donc je ne sais pas comment le reproduire.
REMARQUE: Et, oh, je viens de faire les parties Header always set, pas la partie Rewrite*!
Je suis tombé sur cette question après avoir constaté que les requêtes dans Firefox étaient bloquées par le message suivant:
Raison: la demande de la SCRO n'a pas abouti
Après m'être tiré les cheveux, j'ai découvert qu'une extension Firefox nouvellement installée, Privacy Badger, bloquait les requêtes.
Si vous en venez à cette question après vous être gratté la tête, essayez de vérifier quelles extensions vous avez installées pour voir si l'une d'elles bloque les demandes.
Voir Raison: la demande CORS n'a pas abouti sur MDN pour plus de détails.
Il suffit d'ajouter
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
dans le fichier .htaccess à la racine du site Web auquel vous essayez de vous connecter.
Si vous ne possédez pas de "vrai" certificat (et donc un certificat auto-signé), dans FireFox, vous pouvez accéder à:
Options > Privacy & Security > (scroll to the bottom) View Certificates > Add Exception.
Là, indiquez l’emplacement, par exemple: https: //wwww.myserver: myport
Essayez ceci, cela devrait résoudre votre problème
Dans votre config.php, ajoutez www pre dans votre domain.com. Par exemple:
HTTP define('HTTP_SERVER', 'http://domain name with www/'); HTTPS define('HTTPS_SERVER', 'http://domain name with www/');Ajoutez ceci à votre fichier .htaccess
RewriteCond %{REQUEST_METHOD} OPTIONS RewriteRule ^(.*)$ $1 [R=200,L]
J'ai rencontré un problème similaire, et je pense qu'il est valide d'être enregistré comme je l'ai corrigé:
J'ai un système construit essentiellement sur Symfony 3. À des fins d'auto-apprentissage et de performances, j'ai décidé d'écrire quelques scripts à l'aide de GoLang, également une API à accès public.
L'API My Go attend les paramètres de format Json et renvoie également une réponse au format Json
Pour appeler ces GoApi que j'utilise, la plupart, $ .ajax (jQuery) Le premier test était une déception: le (non) célèbre "Cross-Origin Request Blocked" apparait! Ensuite, j'ai essayé de définir le paramètre "Access-Control-Allow-Origin: *" sur Apache conf, htaccess, php, javascript et partout où je pouvais le trouver sur google!
Mais même erreur frustrante !!!
La solution était simple: je devais faire des requêtes "POST" à la place de "GET".
Pour y parvenir, j'ai dû ajuster GoLang et JavaScript pour utiliser GET! Une fois que c'est fait, plus de demande d'origine croisée bloquée pour moi !!!
J'espère que ça aide
PS:
J'utilise Apache et Vhost, sur Directory Block, j'ai
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Rappelez-vous: "*" signifie que vous accepterez les demandes de n'importe qui !!! (Ce qui peut être un manque de sécurité) Dans mon cas ça va, parce que ce sera une API publique
PS2: mes en-têtes
En-têtes de réponse
Access-Control-Allow-Credentials true
Access-Control-Allow-Headers Authorization
Access-Control-Allow-Methods GET, POST, PUT
Access-Control-Allow-Origin http://localhost
Content-Length 164
Content-Type application/json; charset=UTF-8
Date Tue, 07 May 2019 20:33:52 GMT
En-têtes de demande (469 B)
Accept application/json, text/javascript, */*; q=0.01
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Content-Length 81
Content-Type application/x-www-form-urlencoded; charset=UTF-8
Host localhost:9003
Origin http://localhost
Referer http://localhost/fibootkt/MY_app_dev.php/MyTest/GoAPI
User-Agent Mozilla/5.0 (Macintosh; Intel …) Gecko/20100101 Firefox/66.0
En ce qui me concerne, il m'est apparu que je mettais l'en-tête de réponse Access-Control-Allow-Origin dans un Host.com spécifique (et correct), mais il a dû être renvoyé sous la forme http://Host.com. Que fait Firefox? Il avale en silence la demande GET et renvoie le statut 0 à la XHR, sans aucun avertissement sur la console javascript, alors que pour d'autres défaillances similaires, cela indiquerait au moins quelque chose. Ai ai.
Pour la postérité, consultez également les journaux du serveur pour savoir si la ressource demandée renvoie 200.
J'ai rencontré un problème similaire, où tous les en-têtes appropriés étaient renvoyés dans la demande ajax pré-vol, mais le navigateur a signalé que la demande avait été bloquée à cause d'en-têtes CORS défectueux.
En fin de compte, la page demandée renvoyait une erreur 500 en raison d'un code erroné, mais uniquement lorsqu'elle a été extraite via CORS. Le navigateur (Chrome et Firefox) a signalé à tort que l'en-tête Access-Control-Allow-Origin était manquant au lieu de dire que la page avait renvoyé un 500.
Pour déboguer, vérifiez les journaux du serveur si possible. Firefox renvoie les erreurs CORS dans la console pour diverses raisons.
Une des raisons est aussi le plugin uMatrix (et je suppose NoScript et similaire).