[Zope-dev] Re: CoreSessionTracking proposal

[Chris McDonough]

> 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