I'm working on a web-based tool which streamlines the work we do at my office. The tools provided to us by our partner have a generic login that our entire floor uses, but it times out every 30 minutes, which is annoying to have to log-into again all day.
What I had done in the past, was create a hidden iframe inside my tool which logs into it by submitting a hidden form on page load, and continuing to submit the form every 30 minutes to prevent a timeout. They can then submit searches to the partner tool directly from my tool (via another, visible form).
I'd like to use jQuery $.post() to both get rid of the hidden iframe, and make it so the only time it submits the login info is when a search is being done. That way it's not constantly sending requests when not in use, but you can still run a search without having to worry about the login timing out.
It would seem the ajax same origin policy is preventing this, so at the moment I'm just having it open a new named window, and then submitting two hidden forms in the target window one after the other.
The problem with this is if the login request hasn't finished, the search request doesn't go through, and they're brought to the login page again. If they close the window and search again it will work, but this is also annoying, just not as much as the original situation.
So other than the fact that you actually have to see the page open up (unless it's in a hidden iframe) what is the difference between submitting parameters via $.post() and submitting a form using the POST method? They look identical in firebug. Is there any way I can set up a callback on the form submission, so it waits for the first request to complete before starting the second?
$.post uses xmlhttprequest to send data. Xhr is restricted under the same-origin policy. Sending a straight up HTTP POST request is not.
When performing a POST request to another domain, you won't be able to access the response with JavaScript (even if you submit the form to an iframe).
When using XHR however, you have full access to the response, so you could do many bad things - e.g. accessing pages where the user is logged in, snooping around in his corporate intranet etc.
So the XHR restrictions are not to avoid CSRF but to avoid disclosure of privileged information.
The ajax same-origin policy is to stop sending your information over the net to their personal server, without you being aware of it happening. Page posts to other servers are not recommended, and may fail.
Can you resolve it? You can replace the form submit with jq to wait for the login status to be completed, and then submit the form, however, I am not sure this is a good idea - a spin loop usually indicates a design error.
How much control over the code do you have? Can you make the submit do a login, and on return send the search? Or make the search not require the login?
来源：https://stackoverflow.com/questions/9033513/why-is-post-subject-to-same-origin-policy-but-submitting-a-form-with-method