[Zope-dev] Re: CoreSessionTracking proposal

[Chris McDonough]

> > Are you suggesting that the session token should actually
> > store session
> > data?
>
> As an alternative SessionManager, it appears to have some advatanges that
> others do not.

Hmmm.  Please smack me if I'm wrong, but I'm not clear on how it differs
much from not keeping session-related data in the token.  I guess you could
argue that a session token that holds application data is "more random" due
to the nature of its composition, and due to that it can't be "guessed" as
easily (I doubt anyone would even try).   One of the purposes of the random
element of the session token in the current implementation is to address
this "token guessing" risk.

However, in either case (app data in token or app data key in token), if the
token is stolen, it can still be used by the "robber" to see the data that
relates to it (made available by the application which relies on the
server's unpackaging of the token).  This is a different risk, the "token
theft" risk.  Example:  if you get a tree tag token from somebody, and plug
it into a URL on your browser, it'll work happily.

Without a client-checking scheme (such as encoding the IP address in the
token), a token theft attack is very easy.  As voiced by others in the
thread, client-checking is not reliable, should not be a default, and maybe
shouldn't be included as an option at all.

But all of these ponderings are kind of moot, because session data can be
arbitrarily large (session data on the order of a megabyte will probably not
be uncommon), so the data can't realistically be embedded in the token
anyway.

> Its also the only sensible option that lets you bookmark your place in a
> session, and return to it much later (which interests me more).

I don't understand what you mean... a session token that doesn't include
application data has the same property.  That's essentially its reason for
being around at all.  (If you're concerned that the session token isn't
URL-compatible, it is... the current implementation lets the session token
be transferred via a query string, inlined URL elements, or as a cookie
value).  Parts of the token *never* expire, so you can happily bookmark
something with a token value embedded (or receive and continue to resend a
persistent cookie).

> Isnt the tree tag an example of one Session use case? It smells alot like
a
> session to me.

Probably, yes.  Although it will probably not be reimplemented to use the
session machinery in the near future (dont fix it if it aint broke! :-).