Re: [Zope-dev] CoreSessionTracking proposal
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
Re: [Zope-dev] CoreSessionTracking proposal
Chris McDonough writes: 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? Hash them as GUF does. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
Dieter Maurer wrote: Phillip J. Eby writes: 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. I would be very happy with this. Good, that's what it is now. :-) 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. Do we need a special permission for this? All users will have it (when sessions are used at all). Thus, why clutter the (already cluttered) security management screen with an additional permission. It is advantageous to prevent certain users from accessing session data (such as nonanonymous, non-management users with TTW scripting capabilites) so they cannot arbitrarily examine session data values. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CoreSessionTracking proposal
I just read the CoreSessionTracking proposal. I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. I tend to refuse long living cookies and as sites continue to send cookies on any request, I disable cookies all together. If this means, a site can not be visited, I stop visiting the site. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. Sessions may contain confident information that must not be revealed to other users. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
DISCLAIMER: everything I'm about to say is my understanding based on my discussions with Chris about how to do session management, and does not necessarily reflect the current state of the session management code that he is developing, or what will end up in the Zope core. :) At 09:27 PM 9/30/00 +0200, Dieter Maurer wrote: I am very concerned about the "long living browser id". * Why should a browser id live longer than the session data maintained for the browser? It doesn't need to, necessarily. However, since the session data is decoupled from ID management, the browser ID needs to live at least as long as the longest type of session handled by the site. This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day. Correct. Of course, if the site *also* contains session objects that have a life on the order of a day, then at least one cookie set by the site must have that longer lifetime. 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. * 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. * 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. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). No such policy is necessary, since access to the session data objects themselves is gated. You can't get to the session object unless you have management rights on the session data manager itself, or if the session data object is for "your" session -- the session for the current REQUEST. Once you have retrieved that session data object, what you can do with it is entirely dependent on what the object is. For example, a shopping cart object might grant Anonymous users access to place or remove items in it. Other types of session data objects might grant permissions to record click-tracking data, but not to view it. Nonetheless, most of these permissions issues are moot under normal circumstances, unless you are granting anonymous users the ability to create DTML or other executable methods in your site. Session data objects are not directly accessible through the web under normal circumstances without management access to the session data manager object. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] CoreSessionTracking proposal
"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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
