17

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?

sicks
  • 757
  • 8
  • 23

3 Answers3

28

$.post uses xmlhttprequest to send data. Xhr is restricted under the same-origin policy. Sending a straight up HTTP POST request is not.

Doug W
  • 105
  • 6
tkone
  • 22,092
  • 5
  • 54
  • 78
  • I can't guess why this was down voted. Seems correct to me. +1 – Andrew Barber Jan 27 '12 at 13:10
  • Downvote removed. I thought the user was asking for an explanation *why* only XHR has the restrictions - that's the problem if the subject is a full question that differs from the body and people only read the subject carefully :p – ThiefMaster Jan 27 '12 at 13:12
  • is way to send a straight up HTTP POST request without actually opening the page? – sicks Jan 27 '12 at 13:14
  • Kind of? You can make your iframe do it (submit a hidden form), but it'll then redirect to the next page on the remote server. And being that its a different domain you wont be able to control the iframe anymore. You could always remove it and readd it I guess when youve deteremined that they have completed logging in. – tkone Jan 27 '12 at 13:19
  • but no way to do it without an iframe? – sicks Jan 28 '12 at 05:38
  • Probably not. There might be something you could do with ActiveX, Flash or Silverlight, but I'm not a Flash or Silverlight or ActiveX developer at all. If you REALLY need this functionality you'll either need to get the site you're using to set the correct set of HTTP headers to allow CORS or you're going to have to figure out someway to submit a form without changing the page the person is currently on. An iframe seems to be your best solution here. – tkone Jan 28 '12 at 17:06
  • THIS is precisely the kind of knowledge that frontend devs have that backend devs neglect. Thank you VERY much. – Orubel Dec 23 '18 at 21:16
19

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.

ThiefMaster
  • 310,957
  • 84
  • 592
  • 636
  • Can you back that up? If I send a post request in a raw http client ( like curl ) I have access to the response and I have yet to see the opportunities you describe. How would the javascript have an advantage over an http library with access to more resources? And what if I simply used a browser that did not enforce same origin policy, which is imposed at the client level, not the server? – Anthony Nov 03 '13 at 16:19
  • 1
    When using a HTTP client *you* initiate the request and control which data (e.g. login cookies) you send. But you usually do not have control over the JavaScript a website uses. For example, here on Stack Overflow a simple GET request is enough for me to view privileged information only available to moderators. Now another website could (if it wasn't disallowed via the x-frame-policy header) use an iframe pointing to an URL containing such information - but thanks to the same-origin-policy it has no way to access the data on this page. – ThiefMaster Nov 03 '13 at 16:49
  • Yes, but that's why same origin policy is good and in place. You indicated that form posts over ajax were more vulnerable because of js access to response putting server at risk more than any xhr attack. I think what you meant was that same origin policy ( in general and not specific to OP question) protects the server as much as the user. A valid point, but your answer suggests it is specific to form posts, which could mislead readers into thinking there is some other mechanism in place besides same origin policy. – Anthony Nov 03 '13 at 17:04
-2

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?

Schroedingers Cat
  • 3,099
  • 1
  • 15
  • 33
  • Right now it does submit the login, and then the search, but there's no way to tell if the login request has completed before doing the search. – sicks Jan 28 '12 at 05:03
  • "Page posts to other servers are not recommended, and may fail." < Many many pages (and indeed protocols, such as SAML) use form posts to other servers. Where is this recommendation? – metadaddy Apr 07 '14 at 17:25