3

We're using JQuery AJAX to login. The login service issues a HTTP 302, with the location being the GET for the user logged in, or (in the case of a log in failure), a REST endpoint that always returns a not authorized HTTP status. At the same time as the 302, we issue a set cookie for the JSESSIONID. The cookie is a HttpOnly cookie.

When using a straight HTTP form post, the redirect works fine, and everything is set. When using JQuery AJAX, the redirect to the GET /user/{userId} doesn't work as the cookie is not sent with the second call. This failed second call should trigger yet another redirect to the auth-failed endpoint, but it actually doesn't. Inspecting it, I see that the second call gets "canceled". What does that mean, and how do I fix the problem in the first place?

Jeff Wang
  • 1,837
  • 1
  • 15
  • 29
  • Similar issue and how it was solved here: http://stackoverflow.com/questions/199099/how-to-manage-a-redirect-request-after-a-jquery-ajax-call – jfriend00 Mar 30 '12 at 01:25

1 Answers1

1

It's possible you are falling foul of the same-origin policy. Is the domain you are logging in to the same one that the page/script file was served from?

If not you'll need to use CORS (cross origin resource sharing) to get the cookie to stick.

You can learn more about it here:

http://www.html5rocks.com/en/tutorials/cors/

https://developer.mozilla.org/en-US/docs/HTTP_access_control

Darren
  • 2,888
  • 1
  • 23
  • 34
  • Just cleaning up an old question here. While this answer was not the full answer, it's close enough. Basically, what I needed to do was to check the full description for the JSessionID. There are 2 things at play. 1) was that the domain for the login was HTTPS while the domain for the GET was HTTP, thus running into the CORS issue as Darren mentioned. 2) was that there was a path (/auth vs /rest) issue in the cookie, which caused the CORS fix not to work either. Fixing the path issue finally solved the problem. – Jeff Wang Apr 02 '14 at 22:48