At 10:44 PM 9/30/00 -0400, Chris McDonough wrote:
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
Chris McDonough writes:
The random element of the token is currently five characters. I may
need to "up" this. The secure cookie requirement is already reflected
in the use cases and in the current implementation. Anybody have any
other bright ideas about how to make session tokens
Dieter Maurer wrote:
Phillip J. Eby writes:
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
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
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
"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
