[Zope] Zope cookies data point

[Christopher N. Deckard]

I kind of think that that problem is fine.  Why should the "admin"
account be shared to begin with?  Create users who have the access
that they need to manage the system.  Then there is no stepping on
feet, and you know who did something.  Leave the "admin" account
for when things are really borken.  Or does that go against what
that account is for?  I'm not sure our Zope server even has the
ability for an "admin" account.  :-)

-Chris

On Mon, 26 Aug 2002 17:02:00 -0700, "Charlie Reiman"
<creiman@kefta.com> spoke forth:

> 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
> > >
> 


-- 
--------------------------------------------------------------------
    Christopher N. Deckard      |     Lead Web Systems Developer
      cnd@ecn.purdue.edu        |    Engineering Computer Network
  http://eng.purdue.edu/ECN/    |         Purdue University 
---- zlib.decompress('x\234K\316Kq((-J)M\325KM)\005\000)"\005w') ---