From: Joerg Heinicke <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Need Session Help! Date: Sat, 27 Sep 2003 00:55:52 +0200
Sonny Sukumar wrote:
Hi guys,
I know I've brought up some session questions before, and I gained great insight from those discussions, but there's some issues I want to understand better before I make implementation decisions. Assume the context of a B2C e-commerce site when considering these issues....
---Assume URL encoding is being used because a customer has all cookies turned
off.
1.) Customer puts a few items in her shopping cart.
2.) Customer logs in to view some account details.
3.) Customer then sees her friend on IM and copies a product page URL to her
friend. This URL contains her session ID.
4.) The friend clicks on the link and views the product page. However, she
now can click on "My Account" or whatever or "My Cart", and because she'll
appear to be the first customer (she has the same session ID), she can view
all the personal details she shouldn't be able to.
What's the best way to go here?
What about binding the session on an IP address? As I wrote the last time I don't like cookies (security problem if somebody does not logout explicitely).
With either URL encoding or session cookies you're going to be logged in if you don't explicitly log out (i.e. click a "Log out" link on the site). This is just because closing the browser still leaves the session object in memory on the server until it times out.
Having said that, session cookies do *not* require an explicit logout (from what info I've gathered) because they're resident in memory and not stored on the hard drive, so closing the browser destroys the session cookie. Closing the browser with URL encoding, on the other hand, still potentially leaves that session ID copied to somebody who shouldn't have it, written to some web server log, etc.
That's why I prefer session cookies to URL encoding, although I do understand that some % of people choose to block all cookies entirely.
For link rewriting you have the problem above.
So why not testing server side if the login for a specific session was done using the same IP as the current request. The friend who got the copied link has not a valid IP/sessionid combination - and has to login itself.
Yeah, that's a good idea (in theory at least) if you're going to use URL rewriting. I suppose one could get the IP with Request.getRemoteAddr() and get the session ID with Session.getId(), but then you'd need to maintain a mapping between all the session IDs and all the requesting host IPs within your application. This seems like duplicating the session management effort that Tomcat is expending, so isn't there some way to get Tomcat to check that a sent session ID matches with a previously recorded IP?
Sonny
Joerg
_________________________________________________________________
High-speed Internet access as low as $29.95/month (depending on the local service providers in your area). Click here. https://broadband.msn.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
