From: Tim Olson <[EMAIL PROTECTED]>
> How much overhead does session replication actually cause vs. > fetching > everything from the database on every request?
session replication across a cluster can be very expensive because session modifications are O(n) where n is the number of nodes. it's ok if your sessions are light, but it could become a network jam with heavy sessions and many nodes.
Good point, although we haven't gotten to the stage where we need a web cluster (we certainly plan to, however).
The shopping cart is the main thing we store in the session during the browsing process, and then much more data is stored in the session during the checkout process. I suppose that's one reason why some of the larger e-comm sites have dedicated servers for the checkout process.
> My concern is that > since URL encoding > exposes the session ID in plain view, it's as good as > compromised despite > using SSL to encrypt it once the customer logs in. > > Was that why you were saying to only use session cookies > everywhere?
yes
Ok, I see, but a session cookie is also compromised in a similar manner before heading into a protected area where the connection is encrypted. Sure, it's not nearly as clearly compromised as with URL encoding, but it is still sent in clear text to the server for each request. I think a Black Hat could snatch it during one of these requests and later use it to request a protected page.
Presumably, Black Hat couldn't use a standard web browser client to pull this off, but it's certainly feasible to write a client app that makes HTTP requests with a specified cookie embedded in the request header. Then the returned data could easily be saved and viewed in a regular browser or analyzed in some other not-so-sophisticated way.
Which reminds me...is it possible to make certain URIs only accessible over an SSL connection? (Or over a certain port? because we'd know which port is the SSL port). But I'm guessing this wouldn't really do anything to help either because Black Hat could just initiate an SSL connection to that port anyway, right?
In any case, to solve the problem, is there some way to force the server (Tomcat for us) to change the session ID referencing the same session once the user logs into a protected area? This would invalidate the session ID that Black Hat stole and not let him make bogus requests to steal sensitive session data.
> --Btw, are there any data indicating how many people surf the > web with > session cookies off? I'm only concerned with session cookies > (which are > only stored in RAM), and not "normal" cookies (which are > stored on the hard > drive).
i'd like to see that data too, but i'm sure it's a very small number. also,
anyone who knows how to turn their cookies off knows how to turn them back
on again.
even people who set IE6 to a more restrictive privacy setting generally
still have session cookies enabled. we get few customer problems that are
related to cookie use.
Interesting..thanks for this insight. Our site will be mostly for college and young working women, so I don't think they really know much about setting/unsetting cookies....at least I hope they don't.
Thanks again,
Sonny
_________________________________________________________________
Instant message in style with MSN Messenger 6.0. Download it now FREE! http://msnmessenger-download.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
