Session management on server to server requests.

[Cindy Smith]

I am doing server to server authentication and I am running into some trouble with session management. Let me try and describe…

I have a login method and a filter where we check the user id and password against values stored in our database. If the id and pwd match, we create a user object and store it into session. I also store the session id and session object into a hash map which lives in the servlet context. The login method returns the session id to the client.

When the client wants data from our server, it sends another request with the session id as a url parameter as a security token. If I find the token in the hash map I know the user has been authenticated and we go get the data. The problem I run into is that every time I call request.getSession().getServletContext() a new session is created even though a session is already created in the hash map. I would like to associate the session object in the hash map to the request object but don’t know how. I don’t have this problem when the user authenticates via a browser and cookies are used.

I tried passing the “;jsessionid=xxxx” as a url parameter to mimic a url rewriting scenario in the hopes that the server would associate the request with the existing session but it does not help. A request.getSession() call will always give me a new session (I have a session listener that logs when a new session is being created).

I hope this makes sense. Any suggestions you may have are appreciated.

[David Newton]

Have you tried the jsessionid method from the browser as a sanity check to see if it's working properly at all?

That aside, most HTTP client libraries (like Apache's HttpClient) include cookie management already--you might check to see if the library you're using does as well. It can help keep everything working the same regardless of client.

[Cindy Smith]

David, thanks for the tip.
I just tried the jsessionid approach with the browser by turning cookies off on Firefox and it works fine.

I displayed a few values from the request object using the browswer and requesting from a java program using the java.net package classes.

From broswer with url rewritting:
httpReq.getSession(true).getId()--> 349057FA3C750BCCF0A0F2593E599A09
httpReq.getRequestedSessionId()--> 349057FA3C750BCCF0A0F2593E599A09
httpReq.isRequestedSessionIdFromCookie()--> false
httpReq.isRequestedSessionIdFromURL()--> true
httpReq.isRequestedSessionIdValid()--> true

From server with url rewritting:
httpReq.getSession(true).getId()--> AEB0FCB972D438BFD88153A484BA5214 (this one is the new session created; it ignored my jsessionid parameter.)
httpReq.getRequestedSessionId()--> null
httpReq.isRequestedSessionIdFromCookie()--> false
httpReq.isRequestedSessionIdFromURL()--> false
httpReq.isRequestedSessionIdValid()--> false


One thing I just noticed is that I have a request parameter in the url before the jsessionid parameter as described below:
http://localhost:8080/easydoc/rest/doc/20013699/page/1?easyDoc_proxyKey=FDB7566E4A3097E95F7B6C723CB9E6B0;jsessionid=FDB7566E4A3097E95F7B6C723CB9E6B0

When I inspect the value of the easyDoc_proxyKey parameter, it includes the ;jessionid as well. It is as if the ";jsessionid=xxx" is considered part of the first parameter.

Any other suggestions are welcome. I wonder what it is in a request from the browswer that allows the server to recognize the existing session and that is not working in this scenario.

[Cindy Smith]

It looks like the url got chopped off. Let me try again.

example

[David Newton]

When you make the request from the browser is the jsessionid after the entire URL, or before the parameter?

I haven't used URL rewriting for awhile so I don't actually recall where it's supposed to be.

[Cindy Smith]

With the browser it is the last parameter. But in my server to server call I had one parameter in front of the jsessionid. I tried the server to server call with just the jsessionid and IT WORKED. I wonder why the first parameter causes problems. Any idea?
Thank you so much for the help.

[David Newton]

It's not a parameter, it's a special case. How are you creating the call? Can you sniff the network and see what's actually being transmitted? Is it possible the library is eating the jsessionid? Did you pursue my previous comment about just using cookies with your HTTP library?

Edit:
See here:

http://magicmonster.com/kb/prg/java/jsp/jsessionid.html

I'm pretty sure that's the issue--it's being treated as part of the parameter, as I (sort of) implied earlier.

[Cindy Smith]

After some more testing it looks like the jsessionid parameter must be the first parameter in the url. In the browswer I did not have any additional parameters, just the jsessionid.
I did not pursue the cookie route as I did not want to have clients running from the server to have to deal with cookies. So it seems my mistake was that I put the jsessionid in the wrong place in the url.
Thanks.

[David Newton]

Most HTTP libraries offer automagic cookie support, and these days I would have thought most people have cookies turned on in their browser, since basically every e-commerce site requires it. Glad to hear it works, though.