I currently have a RESTful webservice which recognises a client via it's session.
I have a client which uses ajax/javascript to access the contents of the RESTful webservice. I allow this to happen by responding to the request with the headers: Access-Control-Allow-Origin
, Access-Control-Allow-Credentials
, Access-Control-Allow-Methods
.
However, although the client can access the content's each request is regarded as a different session as cookies cannot be used across domain.
I don't want to modify my server code to cater specifically for this style of client, i would prefer a work around client side to give a facade of using a session.
Since I don't want to store anything through the session, rather I only use the jsessionid as the client identifier I assumed I could artifically inject &jsessionid=
to the URL to, at least from the server side, make the client seem to be correctly keeping track of the session.
This doesn't seem to work - can someone advise on how I can make my client act as if it is using the same sessionid?
jsessionid
isn't a query string parameter. You'd want to artificially add;jsessionid=...
(prior to any & in the URL), rather than&jsessionid=...
.For background...I made a product called kitgui.com which allows for cross domain communication and simulates on-page saving for content management but actually is talking cross domain through an iframe to a secure server.
You don't have to modify your server code. You can use iframe + postMessage assuming you don't need support for below IE8. All the other modern browsers support that. There is also iframe polling technique as well for lower browsers. You don't need to expose your session id across querystring on non SSL either. You can talk to your iframe to get the state of being logged in or not via javascript. The session info remains on the iframe's domain where it should be.
This link can help you -> http://benalman.com/projects/jquery-postmessage-plugin/