[Zope] Core Session Tracking questions

Chris McDonough chrism@digicool.com
Sat, 3 Mar 2001 16:51:50 -0500


Hi Jerome,

> First question: Say my cookies are set to last 14 days, but my session
data
> manager only stores session data for 60 minutes... What happens? Say a
> visitor comes, sets some preferences, leaves and comes back two days
later. A
> new session oject is created. Are the old cookies "imported" in the new
> object or is the data lost?

The data is lost.  The data container timeout determines how long the data
sticks around, not the cookie timeout (the cookie contains what you can
think of as a "browser id" rather than a "session id", although the docs
claim its a sessionid... this is why the docs go into some explanation of
this phenomena).  In many cases, it's desirable to use a session id as...
well.. a session id, instead of trying to use it to associate data with a
user for time immemorial.  One common pattern is to use a session data
object to store data about the user until they log in.  Then when they log
in, you copy the data from the session data object to an object associated
with the user, and then clear the session data, considering the
user-associated data canonical.

> Second question (not really as important for me): Is a Core Session
> Trackink-enabled site not more vulnerable to DOS attacks? Are there plans
to
> eventually add sometghing to protect against OOM situations due to DOS
> attacks, like limiting the maximum amount of RAM used by core session
> tracking?

Are you allowing people to script DTML or other through-the-web code on your
site?  If so, then, yes, probably.  If not, then yes, perhaps.  ;-)

There is one failure case in core session tracking that hasn't yet been
addressed (even if folks can't script DTML on your site):  because session
data objects are stored in the ZODB, they are prone to conflicterrors on
write.  The data structures used by the session data containers are designed
to minimize conflict, but in the case that lots of folks come in with the
*same* session id at the same time, and they visit a method which writes to
that session data object, your site might experience some denial of service
due to conflicts hogging the ZODB connections.  A determined script kiddie
could make this happen pretty easily with a script that fired off a bunch of
reader threads that pretended to be clients with the same session cookie,
hitting a method which did a session write.  Or it could happen if a
session-encoded URL was posted to Slashdot.  You can minimize the
possibility of this happening (especially if you run a public site) by not
using URL-encoded session ids.

I'd like to minimize the possibility of this failure by writing some code in
the session id manager that rejects multiple requests that claim to have the
same session id in some very short timespan.  But it's a tricky problem,
because there could be a legitimate situation in which this could occur.  In
any case, I haven't yet addressed it.

> PS: BTW, thanks again for Core Session Tracking. So far, it looks really
> cool: powerful and dead simple to use. The documentation in help/ seems
> needlessly compicated, though.

Hee hee... damned if you do, damned if you don't.  Write docs, that is. ;-)