[Zope] Zope cookies data point

Charlie Reiman creiman@kefta.com
Mon, 26 Aug 2002 17:02:00 -0700


Just to point out the obvious: Associating clipboard data with a membership
would make sharing the admin account impossible. Suddenly you could get what
Steve down the hall just copied into your collective clipboard. IHMO, you
can only safely implement such a system if an admin can only log on once
which immediately breaks the model of cross-browser sharing.

In the Great List of World Evils, cookies are pretty far down the list. I
can't imagine the added complexity and weirdness is worth it.

> -----Original Message-----
> From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Chris
> McDonough
> Sent: Monday, August 26, 2002 4:16 PM
> To: Kyler Laird
> Cc: brinegar@purdue.edu; cnd@purdue.edu; zope@zope.org
> Subject: Re: [Zope] Zope cookies data point
>
>
> If you want the data you put in a clipboard associated with your Zope
> userid to persist across site "visits", it sounds like you don't really
> want sessions at all.
>
> Instead you want to associated persistent data with an authenticated
> user (aka "membership").  This differs from cookies inasmuch as cookies
> are associated only with the your client (your browser), while
> membership data is actually associated with a user id.
>
> You could use pieces of the existing sessioning machinery to implement
> membership.  A transient object container in the main ZODB, maybe with a
> timeout of "0", with values that were dictionaries and keys that were
> userids would make a simple storage facility.  But its likely that you
> wouldn't use any of the other sessioning machinery in the
> implementation, and there is likely that an even better storage facility
> could be built.
>
> Sessions are attractive because they will work "out of the box" in any
> recent Zope.  We don't have a membership facility in stock Zope yet, so
> we can't really change the management UI to depend on it.  FWIW, for
> this reason, it would probably be easier to change the UI to rely on
> sessions than it would to rely on membership.
>
> - C
>
>
> On Mon, 2002-08-26 at 18:40, Kyler Laird wrote:
> > On Mon, Aug 26, 2002 at 06:26:19PM -0400, Chris McDonough wrote:
> >
> > > FWIW, Shane mentioned that sessions use cookies, but on the 2.6 branch
> > > (the trunk) it's possible to do "cookieless" sessioning via the
> > > automatic embedding of browser ids in the URL.  It makes for very ugly
> > > URLs, though, and you still need to either post to forms with
> > > Zope-generated URLs or embed the browser id in a hidden form element.
> >
> > Yeah, I've gone through those contortions.  I'd like to
> > avoid doing it again.
> >
> > My preference is to avoid trying to weld "sessions" into
> > HTTP.  When *I* cut something, it should be in *my*
> > "clipboard".  I'm authenticated as me.  That should be
> > enough information to find what I just cut.  It will
> > also work when I'm using multiple browsers (because I
> > still haven't figured out how to use tabs in textareas
> > in Mozilla/Galeon).
> >
> > I like the idea of using the authentication ID as the
> > key for a session manager, but it seems like something
> > much simpler should suffice.
> >
> > Thank you for thinking about this.
> >
> > --kyler
> >