You don't have to worry about multiple users ending up with the same
session. The session ID is a unique value stored in a cookie (or through URL
rewriting) that identifies the session. It may be based in part on the IP
address but it will definitely include some amount of randomness. The only
time a session will get shared is if you have multiple windows from the same
instance of the browser. The session ID cookie isn't persistent so you'll
get a new one the next time you load the browser. This isn't really anything
new, people have been doing it for years.
Aaron
> -----Original Message-----
> From: Alex Smith [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 28, 1999 4:34 PM
> To: [EMAIL PROTECTED]
> Subject: Multiple users per session
>
>
> Folks,
>
> A seemingly simple yet baffling question: how do you have more than
> one user share a session? Scenario: two different users
> coming from the same
> client would like to use an application. This can happen for
> users sharing a
> host or in a case of a proxy when the IP of a client is
> identical for both
> users. A servlet engine may know about some
> RFC-compliant HTTP headers appended by a proxy to the request but it
> certainly wont distinguish between different X sessions
> coming from the same
> host. For now I am simply not allowing session sharing among
> many different
> physical clients.
>
> Session sharing is a problem, because state information
> stored in a session
> gets overwritten by a subsequent user. I can avoid this by
> resorting to some
> not-so-elegant workarounds such as storing maps of values in
> the session
> using globally unique IDs as map keys, i.e.
>
> // Old way
> Object bar = new Object();
> session.putValue("foo", bar);
>
> // Stream the page back to the user
> session.getValue("foo");
>
> // New way
> Hashtable h = new Hashtable();
> String uid = idServer.createUID();
> Object bar = new Object();
> h.put(uid, bar);
>
> session.putValue("foo", h);
>
> // Stream the page back to the user with uid embedded as
> // a hidden field, etc
>
> String uid = req.getParameter("uid");
> Hashtable h = (Hashtable)session.getValue("foo");
> Object bar = h.get(uid);
>
> or using a "nested session" approach (with UIDs):
>
> Hashtably mySession = new Hashtable();
> mySession.put("foo", new Object());
> String uid = idServer.createUID();
>
> session.put(uid, mySession);
>
> I dont regard both of these as elegant, because IMO the API
> should allow me
> to "force" a new session and connect to it later, both of
> these methods
> using a String or Object id as a means of establishing the association
> between myself and the session.
>
> Comments, suggestions and better ways to get around this would
> be much appreciated.
>
> Regards,
>
> Alex.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
