Existe-t-il un moyen de contourner la même politique d'origine de Javascript / jQuery pour l'accès local?

Voici la réponse simple: chrome –disable-web-security

À partir du code source (chrome_switches.h):

 // Don't enforce the same-origin policy. (Used by people testing their sites.) const char kDisableWebSecurity[] = "disable-web-security"; 

Je voulais utiliser jquery.js pour envoyer des appels AJAX à un serveur python Google Apps exécuté sur le port 8080. Juste pour les tests, je voulais exécuter le navigateur et le serveur sur la même machine.

Je ne comprends pas toutes les nuances de sécurité, mais pour un développement temporaire, cela semble être une solution de rechange raisonnable. Tant que je n'utilisais que chrome pour tester avec ce drapeau, ça ne devrait pas poser de problème.

Voici la commande complète pour Mac OS X:

/ Applications / Google \ Chrome.app/Contents/MacOS/Google \ Chrome –disable-web-security

Nous avons eu le même besoin lors du développement de notre application Web. Voici comment nous l'avons fait:

Le navigateur et le serveur ne communiquent que par l'intermédiaire de JSON.
Tout le HTML est rendu dans le navigateur en utilisant PURE (notre moteur de modèle JS).
Le code du navigateur est développé localement comme ceci:

Nous ajoutons un paramètre host dans l'URL de l'application:

 http://localhost/app.html?host=test.beebole-apps.com 

En production, le JSON est envoyé au serveur avec un POST.
Mais ici, la fonction chargée de l'appel ajax réagira au paramètre host et produira une injection JSONP (GET) à la place.

 <script src="http://test.beebole-apps.com/?callback=f2309892&json={...}" /> 

• f2309892 est une fonction temporaire, avec un nom aléatoire, qui indique la méthode qui traitera la réponse
• json est le JSON que nous envoyons au serveur

Cela signifie que vous aurez besoin d'une coopération du backend pour vous servir le json enveloppé dans une fonction de rappel comme:

 f2309892( /*the json here*/ ); 

Sauf une limitation de taille (vous ne pouvez pas envoyer un grand JSON au serveur avec un GET), ça fonctionne comme une brise.
Un autre avantage est que vous pouvez appeler tous les différents systèmes (développement et test) à partir du même localhost.

Il existe différentes façons de contourner cela, selon le navigateur que vous utilisez pour le développement. Par exemple:

• Dans Firefox (Gecko), définissez security.fileuri.strict_origin_policy sur false
• Dans Chrome, lancez le navigateur avec l'option --allow-file-access-from-files

Références: Firefox , Chrome

Sans toucher le serveur –

Le moyen le plus rapide et le plus simple de contourner la même politique de sécurité d'origine dans Firefox est l'installation du complément Force CORS. Cela fonctionne avec n'importe quel service en insérant les en-têtes appropriés dans chaque réponse.

https://addons.mozilla.org/en-US/firefox/addon/forcecors/

Comme il s'agit d'un problème de développement et non d'un problème d'utilisateur final / fonctionnalité, plutôt que de vous concentrer sur l'obtention d'AJAX dans des domaines croisés, configurez votre environnement de développement en tant que proxy pour récupérer les données les plus récentes des serveurs de production. C'est vraiment très simple à faire.

Vous devriez configurer un serveur Web dans votre environnement dev (s'il n'en a pas déjà), puis configurer le serveur pour répondre aux requêtes 404 en récupérant puis en écho sur les données de production. Vous pouvez configurer votre serveur afin que seuls les fichiers de données AJAX soient récupérés (sinon, il sera confus de déboguer d'autres fichiers si les éléments de production commencent à apparaître sur vos pages de développement). Donc, si http://dev.myserver.com/data/json/mydata.json est manquant, votre script 404 obtiendra http://prod.myserver.com/data/json/mydata.json et l'écho au client . La bonne chose à propos de cette configuration est que vous pouvez utiliser des données simulées très facilement: si le fichier est là dans votre environnement de développement, votre script AJAX en aura; Mais si vous effacez ou renommez ce fichier, vous obtiendrez plutôt les données de production. Cette fonctionnalité a été si utile que je ne peux pas la recommander.

Si vous travaillez avec XML, je recommanderais la duplication des en-têtes HTTP dans le 404. Si votre processus 404 répond avec un Content-Type de text/html , vous n'obtiendrez aucun responseXML pour analyser.

Essayez ceci (php curl ayax cross domain – par google ):

http://www.iacons.net/writing/2007/08/02/ajax-cross-domain-proxy/

http://www.phpfour.com/blog/2008/03/cross-domain-ajax-using-php/

http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html

J'ai également eu ce problème en utilisant Chrome et l' --allow-file-access-from-files n'a pas vraiment aidé. Retour au script que mon serveur devait retourner, j'ai ajouté ces en-têtes à la réponse et cela a bien fonctionné:

 'Access-Control-Allow-Origin: http://localhost/' 

Et un autre pour permettre une sorte d'échange de clés

 'Access-Control-Allow-Headers: X-KEY' 

Localhost n'est pas autorisé à utiliser dans CORS http://code.google.com/p/chromium/issues/detail?id=67743 utiliser lvh.me à la place