I just read the CoreSessionTracking proposal.
Great...
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?
Because it's a browser id, not a session id. This terminology may change in later revisions of the code I've come up with, but this is the basic idea.
This means, if the session lifetime is in the order of an hour, the cookie need not live longer than, say, a day.
Not if you want to associate a session with a browser across a long period of time. For example, if you wish to maintain a long-lived "wish list" of items in session storage without requiring a user to log in.
* 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.
The cookie lifetime is configurable, so this is up to the site manager or developer. This is not a problem endemic to Zope or the core session tracking proposal, but to the configuration imposed by the developer or site manager. Lots of people don't mind long-lived cookies, and it's not realistic to limit the functionality of the system based on something that's out of our scope of influence. If you choose not to visit sites that provide long-lived cookies, then perhaps that site's session manager will choose to reduce the cookie lifetime.
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.
The use case description that mentions "add session data objects" is incorrect. That permission will not exist. The overall permission "Access session data" will permit the creation of session data objects, as well as the manipulation of already-created session data objects. Anonymous must be granted this permission (or sessions would be completely worthless, as they would require users to log in).
* I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data.
How do you propose that we recognize one 'Anonymous User' from another?
Sessions may contain confident information that must not be revealed to other users.
Anonymous session data should not contain confidential information. This is what data storage associated with an authenticated user is for. However, the risk of information release is mitigated somewhat (but not much) by the fact that session ids will have a random element. Additionally, the "access session data" permission can be withheld from users who have the rights to create DTML or other TTW methods, thus disallowing them to manipulate a visitor's session data from this code.
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).
This is not possible without authentication. The point of sessions is to allow the developer to associate a namespace across multiple visits by an anonymous user. Requiring a user to authenticate before using sessions defeats the purpose.
Consistency:
* sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking
The identifier is configurable. It should probably start with an underscore to be recognizable as a URL-inlined attribute, but this is up for debate. The ids used within the proposal are only suggestions.
* 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.
I probably misused the term "singleton". Thanks! -C