"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