I know it seems like I'm the only one in the world who doesn't accept cookies, but recently my boss was having problems cutting and pasting in Zope. He'd done it before, but it had stopped working. It turned out that cookies had been disabled on both of his browsers (not sure how). I tried to explain that Zope used cookies instead of saving selections on the server. It was embarrassing. Anyway...I'm willing to pay a small bounty for someone to get rid of cookie dependency in the management interface. --kyler
On Mon, 26 Aug 2002, Kyler Laird wrote:
I know it seems like I'm the only one in the world who doesn't accept cookies, but recently my boss was having problems cutting and pasting in Zope. He'd done it before, but it had stopped working.
It turned out that cookies had been disabled on both of his browsers (not sure how). I tried to explain that Zope used cookies instead of saving selections on the server. It was embarrassing.
Anyway...I'm willing to pay a small bounty for someone to get rid of cookie dependency in the management interface.
--kyler
Doesn't Zope have some nifty session managment features now? I think this session management is server side, why not throw copy and paste data in there? -Brian
Brian Ray Brinegar wrote:
On Mon, 26 Aug 2002, Kyler Laird wrote:
Anyway...I'm willing to pay a small bounty for someone to get rid of cookie dependency in the management interface.
Doesn't Zope have some nifty session managment features now? I think this session management is server side, why not throw copy and paste data in there?
Session management depends on cookies. :-) I guess the session manager could use the authentication token as the session key, which would work for some situations but not others. Here's another thought: when a session is active, reading cookies from the request and writing them in the response could be redirected through the session machinery, since a session is a perfect place to store lots of cookies. If you combined those two ideas, we'd be able to remove dependence on cookies from all Zope apps, including the ZMI, at once. This could even start as a monkey patch product, just to let people try it out without upgrading Zope. Oh, there's a bounty? In that case, it will be really hard. We'll have draft a design document, elaborate, and write Java + assembly code and test it on all platforms. Wow, it'll take weeks. ;-) Shane
Zope makes things so easy. :-) -Brian On Mon, 26 Aug 2002, Shane Hathaway wrote:
Brian Ray Brinegar wrote:
On Mon, 26 Aug 2002, Kyler Laird wrote:
Anyway...I'm willing to pay a small bounty for someone to get rid of cookie dependency in the management interface.
Doesn't Zope have some nifty session managment features now? I think this session management is server side, why not throw copy and paste data in there?
Session management depends on cookies. :-) I guess the session manager could use the authentication token as the session key, which would work for some situations but not others.
Here's another thought: when a session is active, reading cookies from the request and writing them in the response could be redirected through the session machinery, since a session is a perfect place to store lots of cookies.
If you combined those two ideas, we'd be able to remove dependence on cookies from all Zope apps, including the ZMI, at once. This could even start as a monkey patch product, just to let people try it out without upgrading Zope.
Oh, there's a bounty? In that case, it will be really hard. We'll have draft a design document, elaborate, and write Java + assembly code and test it on all platforms. Wow, it'll take weeks. ;-)
Shane
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. On Mon, 2002-08-26 at 14:15, Kyler Laird wrote:
I know it seems like I'm the only one in the world who doesn't accept cookies, but recently my boss was having problems cutting and pasting in Zope. He'd done it before, but it had stopped working.
It turned out that cookies had been disabled on both of his browsers (not sure how). I tried to explain that Zope used cookies instead of saving selections on the server. It was embarrassing.
Anyway...I'm willing to pay a small bounty for someone to get rid of cookie dependency in the management interface.
--kyler
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
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
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
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
On Mon, Aug 26, 2002 at 05:02:00PM -0700, Charlie Reiman wrote:
Just to point out the obvious: Associating clipboard data with a membership would make sharing the admin account impossible.
What's impossible about it?
Suddenly you could get what Steve down the hall just copied into your collective clipboard.
If Steve and I are both using the admin account to perform frequent cut and paste operations, we'd better know enough to deal with this. Why is it that we're using the admin account anyway?
In the Great List of World Evils, cookies are pretty far down the list.
Are you suggesting that I first whine about the horrible HTML and awful grammar/spelling that infests Zope? While it's also embarrassing, it hasn't caused functional difficulties like I described. --kyler
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') ---
Christopher N. Deckard <cnd@ecn.purdue.edu> wrote:
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. :-)
If you create executable content (like DTML or python scripts) using a "normal" account that's Manager, and if later that account is removed for some reason, you're hosed: the executable content won't have any executable roles and so won't work. That's why having a shared, permanent, "admin" account can be a good thing. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
On Tue, 27 Aug 2002 16:25:13 +0000 (UTC), Florent Guillaume spoke forth:
Christopher N. Deckard <cnd@ecn.purdue.edu> wrote:
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. :-)
If you create executable content (like DTML or python scripts) using a"normal" account that's Manager, and if later that account is removed for some reason, you're hosed: the executable content won't have any executable roles and so won't work.
That's why having a shared, permanent, "admin" account can be a good thing.
Ah, I guess we have have that problem, but there are enough people that have Manager in the root to fix things and take ownership of objects owned by no-long-users. -Chris
Am Die, 2002-08-27 um 11.51 schrieb 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. :-) Well, the problem is, that you are forcing a policy (a quite sensible, but still) one the user. There are organisation that rely on multiple users -> one account sharing. Forcing these people change their mindset is not a very clever thing. It's propably a safer assumption that they will just change their webapp server software. :)
Andreas
Am Die, 2002-08-27 um 00.40 schrieb Kyler Laird:
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 Well, there is no such thing as a YOUR clipboard. Especially in cases where there are multiple client sessions open. So associating a clipboard with an user object is plain wrong. enough information to find what I just cut. It will also work when I'm using multiple browsers (because I As long as there is only "one user transaction in progress". Consider cases where you are interrupted, do something in another browser (or someplace else) and then return to your orginal work, ...
still haven't figured out how to use tabs in textareas in Mozilla/Galeon). Well, konqueror works like a charm, I use Mozilla for user testing (as I can kill it easily and make it forget the auth-info in this way :) )
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. Well, a clipboard by design must be connected with the session in some way. Either a direct Cookie or some Sessionbased stuff, ... Or you rename Cut,Copy and Paste (because you change the semantics of the clipboard completly).
Andreas
Chris McDonough writes:
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. Why not use an URL segment to code the session information and use __before_publishing_traverse__ magic (similar to VHM) to manage this segment. URLs would look like:
http://host/S-<session>/path_to_object This way, both relative URLs and absolute URL would work and you do not need to fiddle with hidden fields. We probably would like a way to reference static content without the session add-in, to improve cachabilitiy. Dieter
Why not use an URL segment to code the session information and use __before_publishing_traverse__ magic (similar to VHM) to manage this segment. URLs would look like:
http://host/S-<session>/path_to_object
This way, both relative URLs and absolute URL would work and you do not need to fiddle with hidden fields.
This is the way it works right now. You only need to fiddle with hidden form fields if you don't autogenerate the URL to which the form is posted.
We probably would like a way to reference static content without the session add-in, to improve cachabilitiy.
This is also possible, just drop the browser id out of the URL. - C
Am Die, 2002-08-27 um 00.26 schrieb Chris McDonough:
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. Well, then it's done it the "wrong" way:
There are three kinds of URLs: a) relative b) absolute (with or without hostname) c) Zope-generated ones (img.tag, obj.absolute_url) Now consider how much work they are with these session embedding schemas: I) FORM parameter. a+b need work c can be automated, but still changes how the url can be used when generated. (...url and ...url?session=xy are different. For the first one needs ?param=X and for the second one ¶m=X) II) prefix the URL: consider a mapping where the session id is inserted at the beginning and the application object does the session magic: /myfolder/myobject is redirected to /SessNew/myfolder/myobject /SessExisting/myfolder/myobject doesn't need any massaging. /SessExpired/url either resurrects the session or redirects to a new session. Consider the effects on our three kinds: a doesn't need any work. b must be manually massaged. c can be automated AND it's ending is semantically the same as without session embedded. I'd ratehr hope that Zope 2.6 learns especially the second set: -) It can be made to work quite transparently. -) It can be combined with a cookie session handling. -) With sensible handling of expired sessions it also handles bookmarking well enough. Andreas
Zope 2.5 does "I". Zope 2.6 (post alpha-1) does "I" and "II". What is the "wrong" way? I suggest you check out the Zope trunk before passing judgment. - C On Sat, 2002-09-07 at 02:58, Andreas Kostyrka wrote:
Am Die, 2002-08-27 um 00.26 schrieb Chris McDonough:
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. Well, then it's done it the "wrong" way:
There are three kinds of URLs: a) relative b) absolute (with or without hostname) c) Zope-generated ones (img.tag, obj.absolute_url) Now consider how much work they are with these session embedding schemas: I) FORM parameter. a+b need work c can be automated, but still changes how the url can be used when generated. (...url and ...url?session=xy are different. For the first one needs ?param=X and for the second one ¶m=X) II) prefix the URL: consider a mapping where the session id is inserted at the beginning and the application object does the session magic: /myfolder/myobject is redirected to /SessNew/myfolder/myobject /SessExisting/myfolder/myobject doesn't need any massaging. /SessExpired/url either resurrects the session or redirects to a new session. Consider the effects on our three kinds: a doesn't need any work. b must be manually massaged. c can be automated AND it's ending is semantically the same as without session embedded.
I'd ratehr hope that Zope 2.6 learns especially the second set: -) It can be made to work quite transparently. -) It can be combined with a cookie session handling. -) With sensible handling of expired sessions it also handles bookmarking well enough.
Andreas
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Andreas Kostyrka <andreas@kostyrka.priv.at> wrote:
I'd rather hope that Zope 2.6 learns especially the second set: -) It can be made to work quite transparently. -) It can be combined with a cookie session handling. -) With sensible handling of expired sessions it also handles bookmarking well enough.
- And it's a dangerous nest of security holes waiting to happen, you should be aware of that. Please consult the 2.6 edition of the Zope Book to know more about that. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
participants (9)
-
Andreas Kostyrka -
Brian Ray Brinegar -
Charlie Reiman -
Chris McDonough -
Christopher N. Deckard -
Dieter Maurer -
Florent Guillaume -
Kyler Laird -
Shane Hathaway