This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
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.
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.
Joined: Nov 26, 2007
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:
From server with url rewritting:
httpReq.getSession(true).getId()--> AEB0FCB972D438BFD88153A484BA5214 (this one is the new session created; it ignored my jsessionid parameter.)
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.
Joined: Nov 26, 2007
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.
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?
I'm pretty sure that's the issue--it's being treated as part of the parameter, as I (sort of) implied earlier.
Joined: Nov 26, 2007
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.
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.