We Keep Coding

Cross Origin Post Request

I'm trying to send a post request to a different site, specifically Zoho.eu, to enable me to login with one click. Effectively I want to POST to the login URL, my username, password etc etc.
I have ran into the Cross origin problem and I have looked at many different solutions such as JSONP, the iFrame method, CORS etc but all of these require me to have access to the third party backend which I don't have.
How do I get around this problem? I understand I can use a proxy somehow to enable me to avoid the cross origin problem but I'm not sure?
Thanks in advance.

If I understand you correctly then the short answer is you can't.
A proxy won't help you to create a session in the user's browser and login. When using a proxy you are doing the requests in behalf of the user from your server, and can't set the required session values to the user's cookies for the target domain.
This is intentional. The whole concept of Same-origin policy/CORS was invented so that others will not be able to do something in behalf of a users in a domain they don't own.
I would consider OAuth, it might be the right way for you to implement this kind of cross-domain login flow.

One easy solution (which is only a temporary fix, you will have to find a more permanent solution for production code) is to hard code the name of the server from where the request is coming in your server controller code and allow access from it.

CORS protection is intented.
Zoho provides cleaner way to authentication to their site with OAuth integration. That is cleaner way to integrate.
Documented clearly here on the steps,
https://www.zoho.com/crm/help/api/using-authentication-token.html
Any other mode of authentication is not allowed and may be blocked by Zoho.
Hope it helps.

Request external domain and not care about the response content without using cors or proxy or anything outside of javascript

So a couple of days ago i was looking for something like this and had actually found it but never found a use for it. I know its listed somewhere on mozilla's site but i forget what the function is called.
In anycase i wish to request an external domain that doesn't have cors and does not requir external help from things like proxy's. its a rather recent function added to javascript as when i read about it (before i forgot the name) it was listed as expiremental technology. It's supposedly a safe alternative to CORS the only catch is unlike cors you are not allowed to view the response.
What i want to use it for is to basically see if the status code returned is 404 or 200 so i can tell users whether a specific site is having issues and since the ammount of sites that would be requested is huge if i do it server side id prefer to have it done in a clients browser only on specific pages.

I think you could get by with sending a HEAD HTTP request.

What is the rationale behind AJAX cross-domain security?

Given the simplicity of writing a server side proxy that fetches data across domains, I'm at a loss as to what the initial intention was in preventing client side AJAX from making calls across domains. I'm not asking for speculation, I'm looking for documentation from the language designers (or people close to them) for what they thought they were doing, other than simply creating a mild inconvenience for developers.
TIA

It's to prevent that a browser acts as a reverse proxy. Suppose you are browsing http://www.evil.com from a PC at your office, and suppose that in that office exists an intranet with sensitive information at http://intranet.company.com which is only accessible from the local network.
If the cross domain policy wouldn't exists, www.evil.com could made ajax requests to http://intranet.company.com, using your browser as a reverse proxy, and send that information to www.evil.com with another Ajax request.
This one of the reasons of the restriction I guess.

If you're the author for myblog.com and you make an XHR to facebook.com, should the request send your facebook cookie credentials? No, that would mean that you could request users' private facebook information from your blog.
If you create a proxy service to do it, your proxy can't access the facebook cookies.
You may also be questioning why JSONP is OK. The reason is that you're loading a script you didn't write, so unless facebook's script decides to send you the information from their JS code, you won't have access to it

The most important reason for this limit is a security concern: should JSON request make browser serve and accept cookies or security credentials with request to another domain? It is not a concern with server-side proxy, because it don't have direct access to client environment. There was a proposal for safe sanitized JSON-specific request methods, but it wasn't implemented anywhere yet.

The difference between direct access and a proxy are cookies and other security relevant identification/verification information which are absolutely restricted to one origin.
With those, your browser can access sensitive data. Your proxy won't, as it does not know the user's login data.
Therefore, the proxy is only applicable to public data; as is CORS.

I know you are asking for experts' answers, I'm just a neophyte, and this is my opinion to why the server side proxy is not a proper final solution:
Building a server side proxy is not as easy as not build it at all.
Not always is possible like in a Third Party JS widget. You are not gonna ask all your publisher to declare a DNS register for integrate your widget. And modify the document.domain of his pages with the colateral issues.
As I read in the book Third Party Javascript "it requires loading an intermediary tunnel file before it can make cross-domain requests". At least you put JSONP in the game with more tricky juggling.
Not supported by IE8, also from the above book: "IE8 has a rather odd bug that prevents a top-level domain from communicating with its subdomain even when they both opt into a common domain namespace".
There are several security matters as people have explained in other answers, even more than them, you can check the chapter 4.3.2 Message exchange using subdomain proxies of the above book.
And the most important for me:
It is a hack.. like the JSONP solution, it's time for an standard, reliable, secure, clean and confortable solution.
But, after re-read your question, I think I still didn't answer it, so Why this AJAX security?, again I think, the answer is:
Because you don't want any web page you visit to be able to make calls from your desktop to any computer or server into your office's intranet

Javascript API hindered by Cross Domain API calls

I need to provide a functionality similar to "Share with Facebook" for my social networking site. Facebook uses nested iframes and also xd_receiver concepts. I want to write a JavaScript API(JS file hosted on my domain), which can be used by different sites to call my web server APIs in order to share, post or recommend on my social networking site. I have a few questions -
Even though I provide the JS API, and diff sites load the JS file using the source, if any API call is made, it will again be a cross domain call(If I am comprehending correctly) and will be rejected on the server?
How to overcome such situation?
Is there any other better mechanism to implement this functionality?
Please suggest so that I can proceed with the implementation.

I think the default way is to use jsonp to get around cross domain limitation. http://en.wikipedia.org/wiki/JSONP. It might require a change in your api though. A user requests your api through the src of a script tag passing in a function callback. Your api would return pass your json response to the function specified.

Do you know why they use iframes and not simple get requests with JSONP/Images/scripts?
The answer is security. I cannot write a script that clicks their button which will automatically "like" the page.
Using plain old JavaScript with a JSONP will allow the developer to automatically click the button. Do you want that to happen?

The requests are made by the browser and not from the JS file, so, your requests will be cross-domain every time they did from another domain site.
Your server will only reject cross-domain requests if you implement a referrer validation.
And you can use JSONP if your API needs custom contents from your site...

To allow cross domain requests, you need to set the following Header in your HTTP Response:
Access-Control-Allow-Origin: *
The implementation will vary depending on the back-end you are using.
If the host in the Origin header of the request is anything but the host of the request, the response must include the listed Origin in the Access-Control-Allow-Origin header. Setting this header to * will allow all origins.
For very specific information on cross origin resource sharing see http://www.w3.org/TR/cors/. If you're not big on reading w3c documents, check out MDN's primer.
Note: Internet Explorer does its own thing with regards to cross domain requests. This answer is a good start if you have issues with IE.

How can i get around the same origin policy?

I need to use AJAX to get the content of another page located on a different server from the one the AJAX is loaded from. The AJAX needs to send a POST request then return the result. how can i do this?

Set up proxy on your own server. Have your server call theirs and return the result.

if you control both servers, you can use one of the HTTP header fields for cross-origin resource sharing:
http://www.petefreitag.com/item/703.cfm
https://developer.mozilla.org/En/HTTP_access_control

There is no way to go around that policy. This policy is there for very good reasons.
That is also no problem as long as you're in control over the web application. You could simply redirect the call to the other server from your webserver and pass the result. This would work out like a proxy.

If you want to do that on the client and cross browser, you need some cooperation from the other server.
Either by:
1) using JSONP (inject a script tag with a callback function)
Only GET calls are possible though.
Security is an issue as the script has access to all resources in that page(data, cookies, ...).Here's a post that explain how to sandbox them and keep the data in your page safe.
2) POST looks possible using Kris Zip's window.name technique
If the cooperation from the other server is impossible, the server proxy as described in other answers is, to my knowledge, the only option left.