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
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.
* 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
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
* 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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -