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