[Zope-dev] CoreSessionTracking proposal

[Chris McDonough]

"Phillip J. Eby" wrote:
> Thus, by setting the browser ID lifetime to at
> least as long as the longest session, one avoids having multiple cookies,
> one per session manager.

This is a good point and one that I probably didn't make clear in the
use cases.. it's entirely possible to have a site with hundreds of
session data managers.  Each session data manager may implement its own
policy as regards session data object expiry the type of session data
object(s) it returns, as well as the storage of these session data
objects.  The point of the "browser id manager" is to handle the
requirement to identify visitors between requests on behalf of all the
session data managers in the system, as opposed to requiring each data
manager to handle this identification.  Thus, only one identifer need be
used for all the session data managers in a system.

However, as prompted by a Digital Creations "jam session", there are
going to be changes to the use cases which actually make the "Browser Id
Manager" into a "Session Id Manager" which will generate a "session
token" that will carry both a "browser id" (meant to semipermanent)
*and* a "session key" (meant to exist for the duration of a "session" as
bounded by a "global" timeout period).  This is purely an implementation
detail, driven by the somewhat specious requirement that we allow people
to associate a "session" bounded by one session data manager with a
"session" bounded by another in the same system.  (The implementation is
also driven by my reluctance to store session key state related to a
browserid inside Zope itself... it could be handled internally, but I've
decided to put the "session" state on the client instead, it's easier).

This will be an opt-in feature for session data manager implementations,
and does not change much of the underlying principle of having a
potentially "semipermanent" browser id.  Contributed session data
managers will be free to ignore the (oft-changing) session key component
of the session token, and will be free to implement their own session
expiry policies related only to the browser id component of the session
token.  However, it also means that session tokens (which replace
browser ids as a identification value) will be prone to change much more
frequently, as a new session token will be constructed every time the
"global" session timeout expires, and it will contain both the "browser
key" (potentially recycled out of a received token) and a new "session
key".

This may actually be beneficial (in some twisted, baroque way :-),
because it means that people will be less tempted to set the cookie
expiry time far into the future, as the cookie will be reset more often.

 > >  * I am *VERY* suspicious whenever I get
> >    a cookie with an expiration date more than
> >    a few days in the future.
> >
> >    If Zope tries to implement long living browser ids,
> >    I fear, Zope sites will have a high chance, I will
> >    no longer visit them.
> 
> The actual lifetime of a browser ID will be controllable by the Zope site
> manager.  I agree with you, however, in that the default lifetime should be
> reasonable.  Indeed, I would suggest that the default simply be to use
> cookies with no expiration date, and which therefore only live so long as
> the user's browser is open, be it minutes or days.

This sounds like a reasonable default.

> 
> >  * I do not think "Annonymous" should have
> >    "Access Session Data" permission
> >    with the exception to its own session data.
> 
> As I understand it, the "Access Session Data" permission gives you the
> right to call a method that returns you the session data for the current
> request, but does not give you the right to access arbitrary session data.
> Thus, one only has permission to see one's own session data.

This is true.  If you can guess (or steal) someone else's session token,
however, you will be able to access the site "as that user", though you
still will not be able to arbitrarily view session data object contents,
only what is shown by the application code.  I think Dieter's comments
point out that the overarching requirement that sessioning be useful in
the context of anonymity is at odds with the desire to lock down access
to the data referenced by a session identifier.  I will need to spell
out very clearly in the user docs that session data not be used to store
intensely sensitive information.

-- 
Chris McDonough
Digital Creations, Publishers of Zope
http://www.zope.org