"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