This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I understand (reasonably well) the pros and cons of using cookies vs URL rewriting for session management. I also have an ok understanding of how to code URL rewrites into the tags to ensure that backup method is correctly used.
My question is how things should be handled if one chooses to rely ONLY on cookies. One of the disadvantages of URL rewriting is security related (and not the purpose of my post).
Here's an example of the behavior I'm interested in duplicating. I was working through a Java tutorial last night and as part of the tutorial, I was instructed to disable cookies in my browser. So I did that and went on with the tutorial. I tabbed over to check my email (Google Apps Gmail) and my mailboox had already been redirected to a new screen telling me that I had to turn cookies on.
So Google seems to have a "listener", always listening for whether cookies are enabled and the minute it detects that they aren't it redirects program flow to notify the user.
My application that I'm working through is a standard eCommerce application. What I'm wondering is how to employ a cookies-only approach to session management. I'll politely request that you not try to convince me otherwise...I may still use URL rewriting as a backup. The purpose of my question is to learning about how to monitor whether cookies are enabled.
So, one method I thought of was to have a servlet whose sole job is to detect whether cookies are enabled, maybe using a method I'd write like CheckCookiesEnabled(). It could do this by writing a test cookie and reading it. Then, prior to any action that depends on continuity of the session, I call that method first. If cookies are still enabled, I let flow continue on to the intended action. If not, I redirect to a Google-like page that asks the user to turn cookies back on.
But this seems awfully tedious.
Then I thought about doing this just on the root url and treat it like a "gate". Users would only get thru the gate if cookies were enabled. The problems I saw with this option though are (A) what if a user bookmarks a page beyond the gate and has cookies disabled and (B) what if a user turns cookies off after passing the gate.
So it seems that to have a really robust application, I'd need to always know for sure that cookies are enabled.
Would an appropriate strategy be to assume that cookies are enabled and, whenever I need to store something in the session, use the request.getSession(false) method? If it returns not-null, I can continue on with program flow (knowing that cookies are enabled, because they HAVE to be enabled for the incoming request to be assosiated with an existing session, right?). If it returns null, I could at that point check whether cookies are enabled with my CheckCookiesEnabled() method.
You don't need a separate method to check whether the client accepts cookies. What's actually happens : When the Container sees you call request.getSession(), and realizes it needs to start a new with this client, the Container sends the response with both a "Set-Cookie" header for the session ID, and the session ID appened to the URLs (if you've done response.encodeURL()).
In the next request from this client, it will have the session ID appened to the request URL, but if the client accepts cookies, the request will ALSO have a session ID cookie. When the servlet calls request.getSession(), the Container reads the session ID from the request, finds the session, and thinks to itself, "This client accepts cookies, so I can ignore the response.encodeURL() calls".
|BSc in Electronic Eng| |SCJP 6.0 91%| |SCWCD 5 92%|
Joined: Sep 21, 2010
Thanks Abimaran. Clarification question though:
- we call request.getSession() --> session created
- container sends response with session ID (but let's say we don't use response.encodeURL()).
- user doesn't accept cookies so no cookie written
- In the next request from the client, the session ID is not in the header and no cookie is sent
- the next call to request.getSession() just starts the process all over again
In this scenario, the state never gets "conversational". I follow your logic when you use URL Rewriting. But if you don't use that backup method, it seems that somewhere in the flow you have to have a "check" to see whether cookies are being saved. Otherwise, in something like a shopping cart, the app would never remember what's been added.
By tedious, I meant that because I'm new at Java, it seemed plausible that what I came up with on my own was less-than-optimal. I don't mind doing the work if it's the appropriate way to do it. I was just hoping for an opinion on an appropriate method (maybe either validation that my suggestion seemed appropriate or a suggested improvement).
Thanks in advance if any of you can recommend one (and thanks for the other replies too).