cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sonny Sukumar" <ahimsad...@hotmail.com>
Subject Re: Need Session Help!
Date Fri, 26 Sep 2003 23:24:14 GMT



>From: Joerg Heinicke <jheinicke@virbus.de>
>Reply-To: users@cocoon.apache.org
>To: users@cocoon.apache.org
>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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message