Develop Reference

Are there any htaccess or allow-files to enable Cross Site Scripting? Javascript

I need to send and load JSON data to and from a PHP script on a different domain and while the variables were passed, nothing is returned.
domain1.com/display.php (has Jquery $post() routine to send and load data) to
domain2.com/data.php (php script outputs JSON data) <-- this receives data, but response is not sent to requesting script.
Of course this is due to browser security restricting cross site scripting stuffs.
I've read a bit about JSONP but that's just another extra step.
I remember when I used to do FLASH, i would just uload a policy file to the server on a different domain where I would load data from and everything would just work.
Is there anything like that for JavaScript? if not, WHY the HECK not?! Seems to me like it's a legit, hassle free solution, that's just about as secure as JSONP method, or even more so.
Regards

Since you say "it's Javascript that needs to load the data", I gather this is running in some browser. In this case, the browser is enforcing security, as fas as I know, and fiddling with the server( script)s will not help.
Chrome has a command-line option to turn off XS security (--disable-web-security), and Firefox has a setting in about:config (I think, can't find it right now... sorry).
But I guess there's reason to these security settings in the first place... ;-)

Are you trying to load it on the client? Using PHP+cURL it should be no problem on the server side. If you really need to load cross domain content on the client side you could use the Cross Domain jQuery plugin (uses YQL internally)

How to access the data from different server through AJAX call without JSONP?

I'm working on the project where the client has the back-end code in ServerA, and my front-end code, which is supposed to talk to back-end via AJAX requests is on ServerB, and they are in different domains. Because of the same origin policy, I'm not able to make those requests successfully (neither POST nor GET). Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
I tried to emulate this in my local network where the back-end code is running on 10.0.1.4 (different machine), and I'm accessing it from localhost (apache), but couldn't figure out anything that doesn't require using jsonp. When calls are made, I'm not even seeing anything in the logs in the back-end, but it works fine from the REST client and by just loading the URL for GET requests. How are public API requests implemented that are not using JSONP?
I need at least one method (POST or GET) to work. Thanks.

Is it possible to enable it somehow without changing the back-end code
to handle the JSONP? eg., white list that particular domain, or
something?
Yes, you could write a server side script on your domain that will serve as a bridge between your and the remote domain and then send an AJAX request to your script.
Don't expect miracles. If you don't have control over the remote domain you are busted. The same origin policy restriction that's built into browsers for security reasons busts you. Well, you could always write your own browser that doesn't implement this policy, but I think you get my point.
Common workarounds include JSONP and CORS but they involve control over the remote domain. If you don't have control then read the my previous sentence as well as my first sentence.
Here's a nice guide I invite you consulting that covers some common techniques allowing to achieve cross domain AJAX with jQuery. Then adapt the one that fits best your scenario. And there's always the heavy artillery solution that involves bridging the 2 domains with a server side script which works bullet-proof in 100% of the cases if none of the other workarounds help you.

Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
Hmmm, mostly no. You must allow JSONP or "white list" things via CORS (which is very easy to do). Or you can use YQL as a cross-domain proxy.

Three solutions posted here:
http://devlog.info/2010/03/10/cross-domain-ajax/
I've tried the third option since it just worked for me.. and I didn't have to go through any extra stress as it just handled things just like a regular ajax call.
Updating answer as this was posted 2 years ago:
LINK ABOVE NO LONGER WORKS.
Server side proxy:
the old page also talks about using a server side proxy, which means your server makes a call to another server, grabs all the data and sends it off to a page resting on that server. There is no problem for one server to fetch data from another server. So then your page can make a regular ajax call to that server. I didn't go with this option as it required more manual labor. So I'd suggest going with the option detailed here:
JSONP with jQuery
Make sure the provider supports JSONP.
Set the dataType option to jsonp, and if the provider uses a different GET param other than 'callback', specify the jsonp option to that parameter name.
$.ajax({
// ... Use the AJAX utility as you normally would
dataType: 'jsonp',
// ...
});
jQuery will generate a unique callback name for this request (something like json1268267816). Thus, the reply from a web service would be something like:
json1268267816({'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'});
But jQuery handles it all seamlessly, so you as the developer just handle it like a normal AJAX request using the same jQuery success/failure/complete callback hooks.
Drawbacks:
The first limitation to this method is that you have to rely on the provider to implement JSONP. The provider needs to actually support JSONP -- they need to wrap their JSON data with that callback function name.
Then the next limitation -- and this is a big one -- is that JSONP doesn't support POST requests. Since all data is passed in the query string as GET data, you are severely limited if your services require the passing of long data (for example, forum posts or comments or articles). But for the majority of consumer services that fetch more data than they push, this isn't such a big problem.
However,
Using a library like jQuery that supports JSONP, these details of inserting the special script tag and creating the special callback function are all taken care of automatically. Using a JS library, usually the only difference between JSONP and real AJAX is that you enable a 'jsonp' option.

Cross Domain Query

I've just read this article over at Particle Tree
Is this accurate:
If security is not an issue, a JavaScript based API will actually work out very nicely. If we host a JavaScript file, users of our API can include this file on their page, and call functions from that file. Cross Domain Ajax isn’t a problem since the file sits on our server.
I was always under the impression that would fail when attempting an ajax operation. In fact I'm sure I've written some code to try this, can anyone verify if this is accurate?

In fact I'm sure I've written some code to try this, can anyone verify if this is accurate?
As written, it isn't. The origin of the JS doesn't matter, only the origin of the page and the origin of the data you are trying to access.
I think it is trying (badly) to explain JSONP which would allow you to bypass the same origin policy (since the script and the data are the same thing in JSONP).

You can do cross domain, but you have to set the call up correctly. jQuery, as always, makes it easy. You can set a crossDomain flag in the ajax call.
Please reference: jQuery Ajax Call Documentation

Cross Domain Limitations With Ajax - JSON

When requesting (ht|x)ml with ajax you can only send requests to the same domain. But if you request JSON you can send it to any domain. Why?
I'm told it's for security but why would a website do something malicious via ajax rather than just directly if that makes sense.

Check out this wikipedia article.
The reason why JSON is 'safe' is because you have to pass it through a callback. The remote site will run return JSON and your javascript library will not just run it blindly but try to pass it to a function you specify, like jsonpCallback( response ). Since you aren't running the remote code directly much more is under your control and all is mostly well in the world.

The reason it's called JSONP has actually little to do with JSON itself. Doing a cross-domain ajax request is as simple as adding the <script src="http://url.com/data.js></script> tag to your HTML web page; this is the base concept of JSONP and cross-domain ajax.
What happens is that the data.js file is interpreted by JavaScript. This gives us the ability to get data from that data.js file (which is located on another domain), if for example it loads a function that is available in the current scope.

Here is an example of why someone would hack an AJAX request.
https://blog.codinghorror.com/preventing-csrf-and-xsrf-attacks/
http://directwebremoting.org/blog/joe/2007/04/04/how_to_protect_a_json_or_javascript_service.html

Injecting JSON directly in your page is not secure at all.
You offer to the loaded scripts full access to the resources in your page(data, cookies, logic).
If the injected code is malicious, it can run actions on your server, post back data to their server(POST is allowed cross domain, not the response but your data are sent anyway), etc...
We're building a web app that makes a heavy use of cross domain accesses.
To solve this problem, we came with a rather simple JSONP sandboxing solution.

How to specify an external website for XMLHTTPRequest

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: *