I don't have a testing server I can deploy on easily and i'd like to test some jsonp requests. Whats the best way to do this if i'm just deploying from eclipse on a dev box? Is it considered a cross site request if I deploy 2 instances of a server in eclipse, on separate ports? Is there some way to fake it and test locally within the project?
As far as two domains dont match up you should be fine to test it as a cross site jsonp call .
The term "origin" is defined using the domain name, application layer protocol, and (in most browsers) port number of the HTML document running the script. Two resources are considered to be of the same origin if and only if all these values are exactly the same.
JSONP doesn't require 2 hosts, it just supports it. So wether your JSONP response is coming from a remote server or the same server, it works pretty much the same.
Related
webui-aria2 is a tool that allows controlling aria2 (powerful download tool) through rpc methods from a browser.
Using http://ziahamza.github.io/webui-aria2/, one can control aria2, provided the application is launched with the --enable-rpc option. aria2 basically starts an HTTP server listening on localhost:6800.
Great but I am surprised that the browser (both webkit and gecko) allows a page hosted on github.io to make requests to localhost. How come it does? Isn’t this a serious vulnerability?
Requests to localhost from github.io will be treated like any other cross origin request.
JavaScript embedded on the site can't read the data across origins unless either:
Explicit permission is given with CORS or
A hack such as JSONP is used
Presumably the server uses one of those techniques.
I am developing applications using Angular and the client side is 100% JS. I am about to replace an old application made using ExtJS but I will not change the server-side. Only the client-side be re-coded from scratch.
I would like to work on this project from anywhere and any machine but I need to be able to perform cross-domain AJAX queries with the original server (server-side is ASP.NET MVC with IIS and I don't want to install Windows + everything on all the computers I use). Is there a way to do this easily?
Thanks for your ideas!
PS: JsonP is not a solution for me.
Couple of things:
At the end of the day you have to enable CORS in your server.
You can use a CORS proxy https://github.com/gr2m/CORS-Proxy for development. This proxy will actually change the request header of X-Origin which browsers even can but "won't" because of policy. So you will be able to make Cross Origin Requests.
If neither JSONP nor CORS are availble to you as options then you will have to take help of server side scripting.
You can create a method in your server side code and get the response from desired cross domain url and return the response to your javascript function.
You can use CORS (Cross Origin Resource Sharing)
I'm struggling at the moment with the idea of creating a cross-origin request proxy or not.
I have a jQuery application that interacts with an API, making at least 4 requests to that server on the initial page load. Both servers are completely under my control, but they are on different subdomains. For that reason, I've been heading toward the approach of using JSONP to get around the cross-origin request policies.
However, I'm really missing out on one feature in particular: getting HTTP status codes for the requests. The way JSONP + jQuery work, the request works or it doesn't. If it doesn't, I specify a timeout for the request and if that timeout is reached I assume a failure (there's no way to know otherwise). I'd really like to be able to respond to a 404 vs a 500 error from the API server.
This led me to thinking a local proxy may work better - but it would then tie up server-side resources (server that holds the jQuery application + Sinatra application) instead of client resources (the browser). That can certainly add up when each page load is 4+ requests to the API server, even though it wouldn't block the application from loading.
I understand this is not a true "question" - so feel free to flag this / close it if inappropriate. However, I'd really like to get some opinions on the subject. I'm introducing some complexity by developing a local proxy in Ruby.
I'd stick to JSONP and the direct communication between the subdomains.
Also, you might want to check out (hacky) methods of using iframes for communication. Iframes are not subject to the inter-subdomain restriction. They can communicate as long as both subdomains belong to the same top domain.
JSONP has some limitations and is not your only option. Since you control both domains have you considered using CORS? If not, check it out: http://www.html5rocks.com/en/tutorials/cors/
You can read about JSON-P vs. CORS here: http://json-p.org/
DISCLAIMER: I've already looked at various approaches to solve my issue, so please read this before labeling this as a duplicate question
I have a javascript running on https://xyz.com which has to retrieve information from an application ABC running on the user's local machine say port 8080.
My constraints are that I cannot modify the HTTP headers emanating form the ABC nor do I want the user to install another application which will be a conduit to route my requests through to ABC.
Cross-Domain/Window Messaging Options
a) window.postMessage: Ruled out since I cannot have script running on the local machine
b) XDR Object (IE) or Access-Control-Allow-Origin (Firefox,Safari et al): Ruled out since I cannot modify the header
c) JSONP: Again this will not work since I am unable to enclose the response within the function name
As a workaround, only meant for testing I've added the http://xyz.com to the trusted list and have enabled Access Data Across Domains for sites on this list. AFAIK, this option is only available on IE 5+ browsers. This workaround allows me to send and receive messages from http://127.0.0.1:8080
My question is two-fold
1) If I were to continue with the above approach when I go into production what are the security implications that I'm exposing the user to? Can I plug those holes?
2) Are there any other options that I can pursue to achieve my objective.
PS: I would like to be as far away from ActiveX or Flash as possible, but in case that is the only workable alternative to my current approach then I'll have to toe the line
Cheers
If the local application could serve a single html document, to act as a bridge, then you could easily use Cross-Document Messaging (for instance with easyXDM) together with ajax requests from this document to do this. This is a very simple approach and one commonly used.
easyXDM actually comes with such a document, you can read about it here.
I think that the easiest would be to put a server script on https://xyz.com which will act as a bridge between the javascript file and ABC. Then the javascript file will simply send an AJAX request to it's own server script which will take care of fetching the information from the remote domain. The only other viable solution which would work among most browsers and which doesn't require using some client technology like Flash or ActiveX is JSONP but you have ruled this out because you have no control over the remote domain.
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.