Geek Answers Handbook

Is there any way around Javascript / jQuery with the same origin policy for local access?

Trying to use ajax , getJSON and performs functions like this to retrieve an external URL from a local (non-server) development computer. Is there a way to get around the same origin policy so that I can test locally instead of uploading to the server?

+7
javascript jquery same-origin-policy
source share
8 answers

Here is a simple answer: chrome --disable-web-security

From the source code (chrome_switches.h):

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

I wanted to use jquery.js to send AJAX calls to the Google Apps python server running on port 8080. Just for testing, I wanted to run the browser and server on the same machine.

I do not understand all the nuances of security, but for a temporary development, this seems like a reasonable workaround. As long as I use only chrome for testing with this flag, this should not be a problem.

Here's the whole command for Mac OS X:

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

+6
source share

We had the same need to develop our web application. Here's how we did it:

The browser and server communicate only through JSON.
All HTML code is displayed in the browser using PURE (our JS template engine).
Browser code is developed locally as follows:

We add the host parameter to the application url:

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

During production, JSON is sent to the server with POST.
But here the function responsible for the ajax call will respond to the host parameter and instead make a JSONP injection (GET).

 <script src="http://test.beebole-apps.com/?callback=f2309892&json={...}" />
  • f2309892 - a temporary function with a random name that indicates the method that will handle the response
  • json is the JSON we send to the server

This means that you will need a collaboration with the backend to serve you json wrapped in a callback function, for example:

 f2309892( /*the json here*/ );

Besides the size limit (you cannot send large JSON to a server with GET), it works like a breeze.
Another advantage is that you can invoke all different systems (development and testing) from the same local host.

+4
source share

There are various ways around this, depending on which browser you use for development. For example:

  • In Firefox (Gecko) set security.fileuri.strict_origin_policy to false
  • In Chrome, launch a browser with the option --allow-file-access-from-files

Links: Firefox , Chrome

+2
source share

Without touching the server -

The fastest and easiest way to get around the same source code security policy in Firefox is to install the Force CORS add-on. This works with any service, inserting the appropriate headers in each response.

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

+1
source share

Since this is a development issue, not an end-user / functionality issue, instead of focusing on getting AJAX for cross-domains, your development environment is configured as a proxy server to receive the latest data from production servers. It is really very easy to do.

You need to configure the web server in your development environment (if it is not already installed), and then configure the server to respond to 404 requests by fetching and then repeating production data. You can configure your server so that only AJAX data files are collected (otherwise, debugging other files will get confused if production assets start appearing on your development pages). Therefore, if http://dev.myserver.com/data/json/mydata.json missing, your 404 script will receive http://prod.myserver.com/data/json/mydata.json and repeat it to the client. The best part about this setup is that you can easily use mock data: if the file is present in your dev environment, your AJAX script will get this; but if you then delete or rename this file, you will get production data. This feature was so useful that I cannot recommend it enough.

If you work with XML, I would recommend duplicating the HTTP headers in 404. If your 404 process responds with Content-Type text/html , you will not be able to parse responseXML .

0
source share

I also had a problem with Chrome, and the option --allow-file-access-from-files really didn't help. Let's go back to the script of my server, which was supposed to return, I added these headers to the response, and it worked fine:

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

and another to allow a kind of key exchange

 'Access-Control-Allow-Headers: X-KEY'
0
source share

localhost is not allowed to use in CORS http://code.google.com/p/chromium/issues/detail?id=67743 instead of lvh.me

0
source share

More articles:


All Articles