Re-using jsessionId on ajax xmlhttprequest using jquery

Question

How can I code a jquery ajax() call (e.g. xmlhttprequest) to preserve the session ID (e.g. send the 'jsessionID' cookie already in the browser's cookies)

Our context:

• Two java based web applications
• SSO mechanism logs User into both applications (i.e. has session 101 with application A and session 202 with application B)
• Application "A" uses javascript (jquery) to make rest calls to the Application B
• Application B implemented rest API in Java jersey (fwiw)
• All GET's and "old-school form POSTS" from Application A to B connect to the same session #202 on "session B"
• XmlHttpRequests (e.g. jquery 'ajax()' calls) do not re-use session #202. Each XmlHttpRequest get a new session

Why New Sessions?

The reason: XmlHttpRequest do not pass any cookies to application B. Servlet container sets jsessionid in the cookie. Server does not get the jsessionid

In contrast, JSONP calls (which dynamically generate <script src="http://server/b/page.x">) do pass the cookies.

The questions

• What's the easiest way to get ajax xmlhttprequest calls to pass session id (cookies) to the target application ?
• Any good references on ajax, cookie, xmlhttprequest, and REST?
• Can anyone recommend reading on REST API design and authentication?

Web Sessions, State, and Authentication

I know REST is supposed to be stateless, and re-using web sessions seems somewhat fragile (i.e. as opposed to using OAuth and authentication tokens, as does netflix)

This is the first iteration and we were close to getting things "up and running". This worked fine with JSONP, but XmlHttpRequest posts failed.

thanks in advance

Update:

A naive question indeed.

It turns out that cross-site posting via xmlhttprequest/ajax has inherent security issues and workarounds. Firefox, for example, will not pass cookies with XmlHttpRequest unless you add special headers. Firefox will then do a 'pre-flight check' (i.e. an http OPTIONS call) to the server to see "is this ok?". Your server needs to answer the "OPTIONS" call saying "yes it's ok" before firefox will perform your "post with cookies".

IE and Firefox solve these problem differently (i.e. a bit like javascript circa 1998). I don't konw what IE does, but having lived through 1998, we don't want to really go down that road if at all possible.

We coded a workaround.

None of our team knew this when we started coding. (i.e. "jsonp worked great in the prototype; everything else should also")

References: How Mozilla addresses this problem (http headers and preflight checks) https://developer.mozilla.org/En/HTTP_access_control

Cross Origin Resource Sharing: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

Answer 1

You could also solve this problem by deploying a state-ful proxy. They'd have to be installed on both apps. You'd then make a all your session-based calls thru the proxy and store the remote session data into your local proxy's session.