[Zope-dev] CoreSessionTracking proposal

[Phillip J. Eby]

At 10:44 PM 9/30/00 -0400, Chris McDonough wrote:
>
>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

Huh?  I don't get it.  It's still just an opaque key from the POV of the
session data managers, right?  It doesn't matter how you assign the key,
just as long as it's unique.  The concept of a "browser id" was purely a
*metaphor* on my part to show why you only needed one key, whose lifetime
only needed to be as long as the longest session handled by the session
data managers.  That's also why in the docs I wrote up on the Wiki, I
called the ID handler a "session ID manager", not a browser ID manager.  As
far as I can see, there isn't any need for a *real* browser ID, it was just
a metaphor.


>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).

I'm still lost.  Reluctance to store what state?  Why do you need to store
anything?  Keep in mind that a session data manager just throws away its
record for a given ID when it wants to expire it.  If the user "comes back"
and still has a session cookie, that particular session data manager will
just start a new session with the old key.  No harm, no foul.  If a
specialized session data manager wants to keep permanent records of expired
sessions, it can simply move the record somewhere else and/or give it a
permanent key when it expires.  Or it can give every session a permanent
ID, but simply look up active sessions using the session cookie.  I assume
from the use cases, however, that a permanent record of an expired session
is a rarity, not the rule.  So it seems wrong to me to add complications
just to handle that case.


As for associating sessions between two session data managers, why can't
the simple session cookie concept handle that?  It's only one ID, and so is
shared, right?  I'm not quite clear on what the requirement is here.



>This will be an opt-in feature for session data manager implementations,

Now I'm really lost.  What does the feature have to do with the session
data managers at all?


>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 sounds to me again like the "browser id" concept is being taken too
literally.  I assumed that the global "session ID" would expire and be
reset just as described above.  It sounds to me like you're "changing" to
what I thought we agreed on in the first place.  :)


>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 think you're actually making things more complex than they need to be.
It sounds like the misunderstanding probably stems from the part of the
SessionIDManager Wiki page that reads:

"Session ID's provided by a Session ID Manager never expire. The cookie may
expire, or data associated with the session may expire, but the session ID
never does. It can be thought of as being like a "browser serial number"
that sometimes changes (when a cookie expires, or user reloads a
non-session URL in URL mode)."


What this means is that there is never any reason to issue a new global
session identifier value when one already exists.  However, if the cookie
which *carries* that global session identifier expires, then one may
consider that global session identifier to have expired.  What I was trying
to emphasize is that *you don't need to know when the 'global' session has
expired*.  Only session data managers need to know something has expired,
and they do it by timeout on their local session data objects, and they
don't need any info from the SessionIDManager in order to do that.  That's
why I described it as the session ID never expiring.  The SessionIDManager
just issues ID's.  It doesn't have to remember them, expire them, or
anything else.  It *just* gets the current ID or issues a new one if it
doesn't exist.  That's all.  The properties on the SessionIDManager control
the cookie expiration, which thus controls the lifetime of the global
session token.

Is this making more sense now?  Don't try to implement a "real" browser ID,
there was never intended to be one in the first place.  As the Wiki page
says, it can be *thought of* as *being like* a browser serial number.  It's
really just a session ID, like the one you're trying to "add".  :)



>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.

There are a few things that can also be done to shore up the security.
One, of course, is that session ID's should be hard to guess.  And, it
should be possible to specify to the SessionIDManager that "secure" cookies
(HTTPS only) are required.