[Zope-dev] CoreSessionTracking proposal

[Chris McDonough]

"Phillip J. Eby" wrote:
> 
> At 10:44 PM 9/30/00 -0400, Chris McDonough wrote:
> >
<snip session token description>
> 
> Huh?  I don't get it.  It's still just an opaque key from the POV of the
> session data managers, right?  

Yes.  The only difference is that the actual string placed into the
cookie or read via URL-rewriting.  This is no longer just the browser id
and a random element.  It's a combination of the browser id (browser
key), and a "session key" as well as a random element.  When the session
id manager is asked for the browser id by the session id manager, it
returns it, same as before -- session data managers may still base their
data object keys on browser ids.  However, they may alternately base
their data object keys on the combination of the session key component
and the browser key component if they desire.

The biggest change is that the actual value of the opaque string that is
the *token itself* is not the key used by session data managers to
represent session data object ids.  Instead, the token is decomposed and
session data managers ask for either the opaque string which represents
the browser key - OR -  they ask for the opaque string which represents
a session key/browser key combination.  As they choose, session data
managers may base their data object keys on either of these values.

(see below for rationale)

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

In the original implementation, the token was composed of a browserid
and a random element.  No timeout was imposed upon the browser id
(except possibly for a cookie timeout), and the "browser id manager" had
no concept of any timeout whatsoever.  Session data managers handled all
expiry of objects related to a browser id.  A browser id never expired,
but data objects related to a browserid managed by session data managers
did.

In the new implementation, it's much the same.  Except the token is
composed of a browser key (browserid), a "session key" (which is a
timestamp), and a random element.  The browser key component of the
token stays constant for as long as the conveyance mechanism allows as
decided by the site manager.  The session key component changes when the
sessionid manager session key timeout is reached for the browser that
sends the token.  The token is recomposed when the session key component
changes.  This means that if you're using cookies, the cookie will be
reset when the global session id manager timeout is reached.  If you're
using URL-rewriting, the token will be changed in the URL
representation.

The state that is being stored on the client in the new implementation
(that was not stored in the old) is the session key "expires" time. 
It's encoded into the session key component of the token (currently it
*is* the session key).  This could alternately be done in a dictionary
managed by the session id manager stored on the server which related a
browserid to a session "expires" time.  I chose to do it the former
way.  However, there is no forced coupling between session data managers
and the token composition algorithm.  Session data managers may use
either the browserkey string or the combination sessionkey/browserkey
string as object keys as they see fit.

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

Nothing has changed here.  What I'm describing is purely an
implementation detail to accomodate the "synchronization" of session
boundaries between session data managers.  I think you're getting caught
up in the fact that the actual token value is changing, which means
nothing, as the values its decomposed into have all the properties of
the old implementation.

<snip>

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

Let's dissociate the cookie value from the stuff it represents
(additionally... for the benefit of other folks here, the token need not
be sent via a cookie, it could be part of a URL or some other conveyance
mechanism).  The session id manager handles the details of what goes in
the token, and handles the details of decomposing the token into its
component values.  In the end, after the token has been decomposed,
we're left with a "browser key" and a "session key" as well as a random
component.  Most session data manager implementations will ask for the
browser key, and will ignore the session key.  This usage is analogous
to what is outlined currently in the use cases at CoreSessionTracking.  

However, some data manager implementations will rely on the combination
of the browser key and the session key, notably in cases where *literal*
"session-tracking" is a requirement.  The requirement outlined in the
jam session is a situation where it's desirable to keep session data
managers' "session" boundaries in lockstep with each other.  For
example, if CDNow starts to use Zope, perhaps their internal structure
requires one session data manager for the CD portion of the site and one
for the DVD portion of the site.   If each session data manager had its
own decentralized idea about session data object expiry (e.g. if they
only used the browser id component of the session token), there would be
no way to correlate the data between the actual *sessions* represented
by the session data objects.  It would only be possible to correlate
data between the *browsers* represented by the session data objects. 
Many marketing folks want to know what the heck happens *down to the
visit* when folks use their site.  CDNow would want to know what
happened during user X's session (one discrete visit), and they would
want some way to correlate the information represented by the CD site
session data objects and the information represented by the DVD session
data objects for a particular visit.  The session data objects managed
by each session data manager would be persistent, and the ids of the
session data objects kept within both would be represented by the
combination of a session key and the browser key.  The ids of objects
managed by one session data manager would be potentially identical to
the ids of objects managed by another, and they refer to *sessions* and
not *browser ids*.  This allows CDNow to accurately and easily correlate
the objects managed by each session data manager with each other by
implementing and instantiating two session data managers that make use
of the session key component of the session token as a part of their
session data object keys.

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

I hope I've explained this more clearly above...

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

IMHO, I'm making thing as complex as they need to be, but no more, and I
don't think there's any misunderstanding.  FWIW, I think the requirement
which I'm making the change for blows chunks.  :-)

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

The random element of the token is currently five characters.  I may
need to "up" this.  The secure cookie requirement is already reflected
in the use cases and in the current implementation.  Anybody have any
other bright ideas about how to make session tokens harder to guess?

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