Some comments and notes on your observations are included below.
Bernd WENDER wrote:
> Can anybody give me an exact definition of http session semantics?
>
> Suppose you connect to a classical login page that processes form data
> using an HTTP servlet.
> I observed the following:
>
> 1. If you connect more than once from the same browser instance, you most
> likely get the same
> session id (Iexplorer:yes, Netscape communicator: yes, Jazilla: no).
These differences are based on how the various browsers deal with cookies and
multiple windows. The answer for IE is actually "yes or no" depending on how you
have the configuration properties set. Forcing the use of URL rewriting can get
you to a "no" answer in all cases, if that's what you want.
There are large groups of users with perfectly legitimate reasons to want the same
session ID or different session IDs, when a user opens multiple windows.
Unfortunately, since the differences are client side things, there's not much the
server can do about it.
>
> 2. If you connect from two different browsers running on the same machine,
> you possibly get the same
> session id, e.g. with Iexplorer and Navigator on some machines in our
> network.
That is one I've never seen, because the browsers manage their cookie databases
independently. The only issue for me has been multiple windows opened by the same
browser.
>
> 3. The only way to be sure to get another session id seems to start browser
> instances on different
> machines. But I'm not even sure if this is true.
As above, I haven't seen your case with different browsers on the same machine.
Using the same browser, you would want to use a servlet engine that allows you to
disable cookie use (or turn off cookies in your browsers) if you want separate
session ids.
>
> 4. A session stays open and its id will possibly be reused if the browser
> instance is terminated.
>
The server has no clue that the browser instance was terminated (unless you put in
some JavaScript code in the unload handler on every page to send a request saying
so). Therefore, the session has a timeout interval that is defaulted by the
servlet engine, but you can set yourself with setMaxInactiveInterval.
Most servlet engines set their session ID cookies to expire when the browser is
closed, so when it's opened again a new session will be created. However, if URL
rewriting is being used, and the user bookmarked a URL with a session ID included,
they will be continuing the old session (if it hasn't timed out yet). You have to
be aware of the semantic differences between the two approaches.
The semantics of calculating the session ID are engine-specific, but I would think
an engine that actually reused an old session ID is broken. For example, Apache
JServ uses both the current date/time and an ever-increasing serial number to
create a session ID when a new one is required, so you're never going to get a
duplicate. The algorithm that JSWDK uses will become visible once the source code
is contributed to the Jakarta project (http://jakarta.apache.org), so we will all
be able to evaluate this for ourselves.
>
> These facts impose serious problems to my application, e.g.
>
> What if a user logs in, closes the browser, and afterwards another user
> logs in and gets the same
> session id? What should the login processing servlet do in that case? It
> could cancel the old
> session and fetch a new one. But how can it be sure that the first user has
> really quit? If this is
> not the case, it would cancel the session and destroy user specific data,
> which is not very nice.
>
If you can reliably demonstrate that the same session ID got assigned to what is
really a new session, that is a bug that should be submitted to the servlet engine
provider.
If you want the first user to quit, you should provide a "log off" capability in
your user interface. The servlet or JSP page that receives this request should
call invalidate() on the session, which will immediately get rid of it. Of
course, you still have to deal with the fact that people will forget to log off
and will just wander away -- that's the nature of the web.
>
> Is there a generally accepted mechanism of dealing with these problems? I
> implemented methods,
> which check, if a username/password combination match a session, but all I
> can do is prevent
> users from accessing session private data of other users by locking them
> out. I don't believe
> that this is the recommended way. Can I even force the closing of a session
> when a browser
> is terminated?
>
> In short, if there was a mechanism which allows me to force the creation of
> a new session would help
> me a lot. Does such a mechanism exist? Hope somebody can help. Thanks in
> advance!
>
If you know you want to create a new session, just invalidate the old one
(session.invalidate()) and ask for a new one (request.getSession(true)). The
challenge, of course, is knowing when you want to do this.
>
> Bernd
>
> PS: our environment: JSDK 1.0 (SUN) on WinNT, different browsers on WinNT
> in a LAN
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
