[Zope-dev] CoreSessionTracking proposal

[Phillip J. Eby]

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.