I have a home server in domainX, it returns HTML page containing
js part, which should GET data from domainY.
I can't control domainY return, which means that it it will not return any Allow-Origin headers etc.
I can't use JSON either because domainY does not support it.
postMessage may not work either, because I need to make search query
https://domainY/cars=blue&price_max=10000 etc.
I guess GET is the only way (XMLHttpRequest). I would like to avoid cors proxy because I try to keep server IO usage as low as possible.
Is there any tweak I could try without doing everything in the server side?
NO
The Same Origin Policy is designed to protect information that is private between the owner of the browser and the owner of domainY.
You can't get the browser to fetch arbitrary data (with the benefit of the browser's cookies and the browser's IP address) and then make it available to your JavaScript.
domainY might me my webmail, e-banking, or secure corporate Intranet. You aren't allowed to touch it using my browser.
Related
I'm looking for a trick to access an API on a server that I don't have access to using html/javascript. Usually browsers block this for safety reasons. Public APIs like google therefore support CORS headers that let the browser know that the source can be trusted.
I need the solution to be client side because the external API might not be accessible to the hosting server. I do not have access to the API providing server. Therefore options like JSONP and enabling CORS headers are not viable options.
I need a bit of creativity; options I'm considering:
building an application in c# or whatever that can connect to the server and then open a browser. I don't like this option much
Loading a java applet in the page that does the server connection. Also not really great (who uses java appletsanymore)
Thanks in advance,
You can create a simple server what acts as a proxy to provide you the required endpoints. It can be implemented in anything you can host on a server in the same domain like PHP, NodeJS, etc.. Since it won't run in the browser it will have no problem to access external servers.
If all your target devices support HTML5 you can use window.postMessage() too https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
We have several internal web applications. One of those needs to access all the other applications. Problem is: Same-Orign-Policy.
Actually I did manage to get around it. First of all, the IE is quite sloppy what concerns web security. So, it actually asked me whether I want to have these requests done or not. If I clicked yes, he just executed the cross site requests.
But since most of the users won't use IE, there was the need to make it run in another browser.
So, I tried to make it run in Google Chrome. And after some research I found out, that it will work when I turn of the Web Security by using the execution parameter --disable-web-security.
This did the job. But unfortunately, most of the users won't be using this execution parameter. Therefore I need another solution.
Then I came across CORS. CORS seems to be implemented in Chrome, but it has one drawback (for me). I need to set headers on the server side.
For reasons I won't discuss in here, this is a no go.
So what I was actually wondering about is:
Why will disabling Browser's Web Security do the job, while I need the server to allow the request when using CORS?
What exactly happens inside the browser when I disable the web security?
And is there another way to execute my CSR without adding headers on the server's side or disabling the security?
Thanks in advance
EDIT: JSONP is out of question either
Why will disabling Browser's Web Security do the job, while I need the server to allow the request when using CORS?
The point of the Same Origin Policy is to prevent Mallory's evil site from making Alice's browser go to Bob's site and expose Alice's data to Mallory.
Disabling security in the browser is, effectively, saying "I don't care about protecting my data on Bob's (or any other!) site". This is a dangerous thing to do if the browser is ever going to go near the open web. The option is provided to make development more convenient — I prefer a more controlled solution (such as the URL rewriting options in Charles proxy).
CORS is Bob's site saying "This URL doesn't contain any data that Mallory (or some other specific site, or everyone) shouldn't have access to, so they can access it. Bob's site can do this because it knows which parts of it contain public data and which parts contain private data.
What exactly happens inside the browser when I disable the web security?
It disables the aforementioned security feature and reduces the protection of the user's data.
And is there another way to execute my CSR without adding headers on the server's side or disabling the security?
A proxy. See Ways to circumvent the same-origin policy, specifically the Reverse Proxy method.
I guess you are using AJAX requests, here is another question Ways to circumvent the same-origin policy that has a big detailed answer.
You can use a Flash object (flash doesn't have this problem)
Also about "whats the worst could happen" http://blogs.msdn.com/b/ieinternals/archive/2009/08/28/explaining-same-origin-policy-part-1-deny-read.aspx and http://en.wikipedia.org/wiki/Cross-site_scripting
We're developing a Dynamics CRM 2011 product that has a button in the ribbon that calls an external API. Currently, for this button to work, the following settings need to be changed in the browser (IE):
We would like to avoid this, because many of the target customers for this product are very security conscious. Is there a way to write the code so that it will not require these permissions to be changed, but still be able to communicate with the external API? The code running when the button is pressed in CRM is HTML and Javascript.
Thanks!
Are you in control of the API? If so, look into CORS. With CORS, all you do is basically add a few extra headers to your request response. If you use an AJAX library (like jQuerys $.ajax), you should be able to continue writing code as is. If not, a good article on how to implement cors in Javascript can be found here: http://eriwen.com/javascript/how-to-cors/
To enable cors, read up on http://enable-cors.org/
I don't know anything about this CRM, but other than JSONP, your best bet is to have a server side script act as a proxy.
So, you would create a script within the same domain as the user interface code. That script will then use a server side language (such as PHP) to perform the request to the cross domain script on your behalf. The server side connection has no restriction on which domain it can access, and all the browser knows is that it is sending a request to a page within the calling domain, which is presumably safe.
How you will do this depends on the exact language of choice, but in general you would just need to send the remote API URL as well as any arguments needed to your server side script, which then rebuilds the request to that URL and passes the result back to the client.
I currently have a RESTful webservice which recognises a client via it's session.
I have a client which uses ajax/javascript to access the contents of the RESTful webservice. I allow this to happen by responding to the request with the headers: Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods.
However, although the client can access the content's each request is regarded as a different session as cookies cannot be used across domain.
I don't want to modify my server code to cater specifically for this style of client, i would prefer a work around client side to give a facade of using a session.
Since I don't want to store anything through the session, rather I only use the jsessionid as the client identifier I assumed I could artifically inject &jsessionid= to the URL to, at least from the server side, make the client seem to be correctly keeping track of the session.
This doesn't seem to work - can someone advise on how I can make my client act as if it is using the same sessionid?
...I assumed I could artifically inject &jsessionid= to the URL...
jsessionid isn't a query string parameter. You'd want to artificially add ;jsessionid=... (prior to any & in the URL), rather than &jsessionid=....
For background...I made a product called kitgui.com which allows for cross domain communication and simulates on-page saving for content management but actually is talking cross domain through an iframe to a secure server.
You don't have to modify your server code. You can use iframe + postMessage assuming you don't need support for below IE8. All the other modern browsers support that. There is also iframe polling technique as well for lower browsers. You don't need to expose your session id across querystring on non SSL either. You can talk to your iframe to get the state of being logged in or not via javascript. The session info remains on the iframe's domain where it should be.
This link can help you -> http://benalman.com/projects/jquery-postmessage-plugin/
I have a server on our company intranet that runs JBoss. I want to send API calls to this server from my machine, also on the intranet, and get the resulting XML responses using JQuery.
I read the entry on Wikipedia but am confused how that applies to my situation, since our machines only have IP addresses, not domain names.
I have
server URL: 10.2.200.3:8001/serviceroot/service
client IP address: 10.2.201.217
My questions are:
As far as I understand these are different domains, right? So I have to use a proxy to issue JQuery.ajax calls to the server
If I want to avoid doing (2), can I install Apache on the server and server the page with JS code form there? But then the JS will be from 10.2.200.3 and the server is at 10.2.200.3:8001. Aren't these considered different domains according to policy?
Thanks!
Yes.
Yes, different ports mean different origins. This is something that most browsers have done in JS for a while, but it is explicitly described in the HTML5 draft, which is referenced by the XMLHttpRequest draft.
If A and B have port components that are not identical, return false.
If the port, or address are different, they are different domains. If you need to access information from what is effectively another server you really have two options. One is to write some sort of reverse proxy to pass your requests from the same origin server to the secondary server.
Alternatively, if you are in control of the secondary target, and there's no security risk in providing direct access, you could consider adjusting the secondary server to emit JSON-P responses.