my js file calls uses an xmlHttpRequest to display an rss feed. when i reference the java script within my html page, my browser renders an error: Permission denied. and therefore, my script is being blocked. i am not allowed to change the security settings and would i'd appreciate any work around tips. thanks!
It's called the same origin policy. There's no easy workaround.
Simply put, XmlHttpRequest doesn't allow you to perform ajax calls across domains. Meaning, if you're website is mydomain.com, you can't use XHR to call out to pages (xml or otherwise) on someonelsesdomain.com.
There are work-arounds, typically using flash (less elegant) or webservice proxies (more elegant). Google "cross domain ajax calls" for more help.
Cross-origins call? You can't do that ( at least not directly e.g. need an extension/plugin etc.).
You need a proxy server... a utility that will allow access to foreign (in this case, on another server) material on your own server. Since (as the others mentioned) Browsers have security features enabled to prevent you from accessing content via AJAX on these foreign servers, a proxy will enable you access to this content locally.
this .net method was perfect and easy to implement: http://www.asp101.com/articles/john/megatokyo/dotnet.asp
Related
Is it possible to open sockets and get data from web in JavaScript.
My aim is: to work with web data using JS.
I have looked for XmlHttp/AJAX solution, but I have found one note, that AJAX can be used only for calling localhost programs, which will be used as proxy and then only returns data from web.
It's because of sandbox model in browsers, which don't allow to work with sockets/other sites from JavaScript, and it works only in localhost.
Are there any solutions with JS to work with other world?
Your issue is due to cross domain request security, where you can't asynchronously get data from a domain which doesn't match the current host (this includes subdomains). You can however use jsonp, but this relies on the service that you're quering to supply the data in a jsonp format (a function call with the json data as a response).
If you have no control over the services you're requesting (which i assume you don't), you can use a javascript library, such as YUI or jQuery to perform the cross domain request for you (which typically uses Flash as the data proxy). However this will only work if you the site in question allows cross domain requests from your domain (defined in crossdomain.xml).
Is it possible to do AJAX calls from inside an iframe that has a different domain source?
I've tried script injection but it doesn't work because the iframe's source is secure.
I made a simple fiddle with California DMV website here.
I'm getting DOM exception 8 error. Is it a security issue?
It is not possible to modify or make JS calls in an iframe with a different domain source. This is restricted in all browsers for security reasons.
See the "Same Origin Policy" for a description of how inter frame security works. In a nutshell, there is very little communication allowed between frames on a different domain for security reasons. You cannot make any direct Javascript calls between frames on different domains.
There is a way to make cross domain ajax calls and it involves using JSONP. Basically, you inject a script tag into your own frame and that script tag points to server endpoint anywhere on the web. Since the src value of a script tag is not restricted by the same origin policy, you can reach that server. But, now you need to have a way to get that result back. That is done using JSONP where you specify in your server request a javascript function that you want the returned javascript to call. That returned javascript can have javascript data in it that is then passed to the desired function. JSONP requires cooperation between both client code and the server code since a normal ajax call might not support the extra part of JSONP. But, with this cooperation of both sides, you can get around the same origin policy for server endpoints that support JSONP.
HTML5 has a new messaging system that can safely communicate data (not direct JS calls) between cooperating frames in different domains. See here and here for a description of how the HTML5 messaging works.
Yes it's a security issue because of the Same Origin Policy enforced by most browsers: http://en.wikipedia.org/wiki/Same_origin_policy .
You can look into JSONP http://niryariv.wordpress.com/2009/05/05/jsonp-quickly/ which is specifically designed to get around this.
I have seen server side proxy workarounds for retrieving rss (xmls) from cross-domains. In fact this very question addressess my same problem but gives out a different solution.
I have a constraint of do not use a proxy to retrieve rss feeds. And hence the Google AJAX Feed API solution also goes out of picture. Is there a client-only workaround for this problem.
JSONP is the solution for requests that respond with JSON output. But here, I have RSS feeds which can respond with pure xml .
How do I solve the problem.
Use something like Yahoo! Pipes to serve as your proxy and translate the RSS XML into a JSON response.
Here is an article with instructions and code samples that explains how to do it: Yahoo Pipes--RSS without Server Side Scripts.
If you have control over both domains, you can try a cross-domain scripting library like EasyXDM, which wraps cross-browser quirks and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).
Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.
Another Caveat: there are security implications here-- make sure you trust the other domain's script!
Right now there really isn't a cross-platform solution for cross-site scripting. Do you have control or access to the RSS feeds? If so, why not simply respond with JSON and use JSONP?
There are other things coming down the pike with HTML5, like cross-site messaging (referred to as Cross-Document Messaging) that may be capable of delivering a payload of XML, but last time I checked, they hadn't even fully decided on a size limit for the messaging.
You can see the spec here: http://dev.w3.org/html5/spec/Overview.html#crossDocumentMessages
A solution for cross-domain calls without a server-side proxy is to use a SWF component.
You can script yourself one or use the readily available FLSend
The component uses ActionScript's URLRequest to call remote domains and ExternalInterface to communicate with the JavaScript methods that render your content.
The only way I can think of would be to embed a signed java applet on the webpage to retrive the xml and use javascript to interface with that. I'm not even 100% certain what the java security model is for that at present though but I think it would work.
When using an XMLHTTPRequest in javascript, I want to send it to an external website, rather than the one where the .js file is hosted. To send it to test.php on the current server, I would use
request.open("POST", "test.php", true);
but for the second arguemnt, how do I send it to another website. "example.com/test.php" looks for a file on the current server, and "http://example.com/test.php" justseems to outright fail.
You can't for security reasons. See the same origin policy for JavaScript.
There are some workarounds that exploit browser bugs or corner cases, but using them is not recommended.
The best approach is having a server-side proxy that receives Ajax requests, and in turn, sends HTTP requests to other servers. This should be carefully implemented by sanitizing input and whitelisting the types of requests that are sent, and the servers that are contacted.
This sounds like a bad case of Same Origin Policy, my friend :)
You can't (for the most part) use XmlHttpRequest to get data from an external website. What you can do, however, is dynamically create a SCRIPT tag and reference an external address. jQuery wraps this functionally as part of its ajax handling.
Indeed you can. Not in any browser although.
In Internet Explorer 8.0 there is XDomainRequest, an object enabling cross-domain requests. You would need to properly handle request made with this object on server by sending Access-Control-Allow-Origin header first with "*" or requester domain name.
Since you are doing some hacky things anyway, why not trying to use it on IE8 first?
If you have control over the server, you can use this header in the HTTP reply, although it may not work with all browsers.
Access-Control-Allow-Origin: *
Is it possible to do a cross-site call, in Javascript, to a WCF service?
I don't mind if it's a POST or a GET.
But I've heard that these days, browsers don't allow cross-site calls with either POST or GET.
How can I circumvent this and still call a WCF Service?
There's not a whole lot you can do to circumvent the browser's cross-site scripting blockers. Those blockers stop XMLHTTPRequest's from happening to any domain but the one that loaded the containing script or page.
That said, there is one commonly used workaround: Use JavaScript to write a new entry into the DOM that references a src that is a cross-site URL. You'll pass all your RPC method arguments to this "script" which will return some JavaScript that will be executed, telling you success or failure.
There's no way to do a POST in this manner, the src URL must be a GET, so you can pass arguments that way. I'm not sure if WCF has a "GET only" method of access. And, since the browser will expect the result of the remote tag to be a valid JavaScript object, you'll have to make sure that your WCF service obeys that as well, otherwise you'll get JavaScript errors.
Another common method of circumventing cross-site scripting is to write a proxy for your requests. In other words, if you want to access domain test.com from scripts hosted on example.com, then make some URL on example.com that proxies the request over to test.com in the proper way.
For your example, the proxying is likely the right answer, assuming that WCF doesn't have it's own cross-site scripting restrictions.
Are you using jQuery by any chance? jQuery supports Cross-Domain JSON requests using "JSONP". You will be limited to GET requests, but I've tried it out and it works well! It's also very simple to get working.
See the "Cross-Domain getJSON (using JSONP) " section on this page for details:
http://docs.jquery.com/Release:jQuery_1.2/Ajax
And here's some background on JSONP:
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
Let me know how it goes!
New W3C recommendations are being standardised to allow cross-site requests between trusted parties via the Access Control for Cross-Site Requests specification.
This requires a server serving suitable Access Control HTTP headers and a browser capable of understanding and acting upon such headers.
In short, if a remote host says it likes your domain, and a browser understands what this means, you can perform xmlHttpRequests against that host regardless of the same origin policy.
Currently very few browsers support this functionality. IE8 apparently does (I haven't tested it) and Firefox 3.1 does (I have tested this extensively). I expect other browsers to follow suit quite quickly.
You shouldn't expect sufficient adoption of compatible browsers until 2012 at the earliest.
That's the ultimate solution to the problem. The downside is waiting a few years before it can be used in mainstream applications.
If this is for use within an environment you fully control, such as for an intranet where you can determine which browser is used and where you can configure multiple servers to issue the correct headers, it works perfectly.
To expand on Ben's answer... I extended our WCF service to support JSONP calls from jQuery using code similar to this example from Microsoft:
http://msdn.microsoft.com/en-us/library/cc716898.aspx