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.
Related
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.
I would like to only allow my game to work on some domains. The build version of the javascript by default will work everywhere and is minified and uglified. What might I do in order to "break" the game if used out of the allowed domains?
I was thinking of something that reads the domain name and based on that will break it. But this is easy to trick, just change all instances of the places where I request the domain name and put one of the allowed.
Another one would be to request on my custom service little bits of data. Imagine I'm on the allowed domain and I request a bit of data that varies with the timestap I provide. Also the response will be based on the allowed list of domains. If the source domain in the ajax/post request is allowed, then is sent a "right" bit, if not, it will "break" the game; This would happen every once in a while and within the game.
What do you think? is easily crackable?
In general, javascript (or any client side language) is not the correct place to put security or licensing related code, as it can be easily circumvented by modifying the javascript. Minifying the Javascript will make it harder/slower to modify but will not prevent it.
If there is some server side language involved, then you may be able to investigate a server side licensing solution, but generally server side scripts can also be modified or decompiled by anyone with access to the server.
Another option may be to host the bulk of code on your own server, and any server that wants to use your game would need to send your server a license key via a server to server request to your server, that way the license key is kept private and only your server and the hosting server know it, your server would then respond with a session token which the client may then use to get access to your game. As the license key would be kept private it would make it harder for 3rd parties to intercept it, and without it they wont be able to get a session token. But this only works if there is a server side language involved, if it is all done in javascript then this wont be of much use.
Modify the server so that it returns different versions of the script depending on the subnet address of the client. This way, there is no client dependency on valid (or any) DNS, and the server completely controls the authorisation process.
The client will then receive a version of the application that can then report an error and terminate.
I'm writing a web app with Javascript which needs to access a third-party API (located on x.apisite.com and y.apisite.com). I was using XMLHTTPRequest, but when serving the files from my own local server, this fails because of the same-origin policy.
Now, this web app is supposed to be installed on my mobile device, where any downloaded files will be cached. So, I changed my DNS entries to point x.apisite.com and y.apisite.com to my own local server. I then download the files and then change the DNS entries back to the correct ones. I thought that since the browser thinks that the scripts were downloaded from *.apisite.com, I could now make XMLHTTPRequests to *.apisite.com. However, this does not seem to be the case, I still get same-origin policy errors.
What am I doing wrong?
Here's the basic idea of what I'm doing:
<!DOCTYPE html>
<html>
<head>
<!-- this will actually be downloaded from my own local server -->
<script src="http://x.apisite.com/script-0.js">
<script src="http://y.apisite.com/script-1.js">
...
In script-0.js, I make an XMLHTTPRequest to x.apisite.com, and likewise in script-1.js, I access y.apisite.com.
Practical answer (not recommended): Create CNAME records to the third-party domains from domains that you control, then use those domains and hope that the hosts of the third-party aren't looking at the HTTP Host header. Note that this wouldn't work if the clients attempt to authenticate the third-party hosts either; for example when using HTTPS (some client browsers may force the use of HTTPS in certain scenarios).
Ideal answer: Ask the third-party to authorize requests made by code that came from your origin domain using CORS (some hosts already allow requests from code from any origin, you should check that).
Alternative: If the third-party doesn't want to give clients the go-ahead to make cross-origin requests with code from your domain, then you have to make those requests yourself (from your server). The code you send to the client browsers will then only interact with the same origin, but this also means that users will have to trust you with their credentials if you're proxying requests for them (if that's relevant), or you must have credentials of your own to authenticate your server to the third-party hosts, which allow you to do whatever it is you want to do there. It also means you take the traffic load as well, which may or may not be heavy depending on the application. There are potentially many other implications, which all derive from the fact that you explicitly take responsibility for these requests.
Note: While this may sound a bit complicated, it may be useful to understand the trust mechanics between the user, the user's client browser, the code executing in the browser, the origin of that code, and the domains to which that code makes requests. Always keep in mind the best interests of each party in mind and it'll be easy to find a solution for your specific problem.
Final answer (everybody hates it, but you probably expected it): "It depends on what exactly you're trying to do." (Sorry.)
This SO post lists numerous ways to circumvent this poilicy.
However, I can't tell if any of these are applicable to when you don't have access to the second origin.
Particularly this one, 3rd answer down, you insert a script that calls a script form the second origin.
<script src="http://..../someData.js?callback=some_func"/>
But in general do any of these methods allow circumvention when you are on origin one...and need access to origin two?
Yes, you can circumvent the Same Origin Policy without controlling the second server, but you can't do it without the cooperation of the owner of the second server. Often, as in your example, this is done by cooperating with the JSONP conventions. There is no other way of doing this without proxying the requests to the second server through the first.
Obviously this can't be possible, otherwise the policy would be useless. It's all about preventing you from pulling data from a third host, which is exactly what you are trying to do.
Note that browsers have no notion of what is part of the "private" local network and what is part of the "public" global internet. So this policy exists to prevent arbitrary Javascript code from accessing resources on your local network.
NO, that's the entire point. The SOP can be turned off only if the server specifically allows it thru either CORS or something like JSONP.
Inserting scriptlets is an attack (regardless of if your intentions are good). If I owned a domain and someone did that, they would be banned and reported to the authorities.
The closest you can come is to use server side proxy (i.e. have your js make requests your server, which in turn makes requests to the third party).
I have the main website hosted by a reliable static web hosting service. Which only allow me to host static files like html, css, js etc. Now I have few requirements which would need user Login and data storage. I think I can handle this using App Engine Python.
My app is similar to a Voting module, So i will explain it using its example.
My plan is to configure things something like this:
main website: www.example.com
appengine: gae.example.com
On the main website an anonymous user visits: http://www.example.com/vote.html, he should see current voting status (which has been retrieved from app engine). and a login button (from twitter/facebook). when he logins, he should be able to cast his vote and the vote be saved back to the appengine server.
I can handle most of the things but two. (taking same origin policy into account.)
How do I maintain authentication between two domain names. i.e. www.example.com and gae.example.com.
How do I make HTTP POST request to the gae.example.com from www.example.com and use the returned json data.
Note: I want to avoid iframes as much as possible.
You need to use JSONP.
Subdomains actually violate the same origin policy. This is because some hosted solutions provide subdomains for different users. This would allow users to attack each other's sites.
See: Same Origin Policy - AJAX & using Public APIs
You can maintain login between the two sub-domains by making sure that the login cookie is set on the root domain with subdomain access allowed. The sub-domains will be able to access the cookies of the root domain. See https://serverfault.com/questions/153409/can-subdomain-example-com-set-a-cookie-that-can-be-read-by-example-com for some examples.
I don't believe you can make ajax calls directly to another sub-domain. If the target sub-domain is cooperating and supports JSONP, you can do it that way (you end up inserting a script tag with a call to a script and that script calls you back with the data). Because the loading of scripts isn't subject to the same origin policy, you can work around it, but the target sub-domain has to be configured to allow and support JSONP.