October 2000 - Zope-Dev

Re: [Zope-dev] mailing list 'noise'
by Karl Anderson 03 Oct '00

03 Oct '00

Ken Manheimer <klm(a)digicool.com> writes: > In fact, i'm *really* interested in "turning answers into stories". That > is, not just getting answers to questions, but preserving them in a way > that makes them easy to find when they're next needed - organizing them so > they collectively serve to describe the topic they're about, to make the > topic, as a whole, discoverable. While i think there are many modes of > discussion that can serve this purpose, depending on the application and > collaborative context, i think mailling list discussion threads need more. > They're a step towards that building-together, but fail to organize beyond > that - so the answers they provide are fragmentary glimpses into the topic > at hand. > > One key way wiki documents help bind the fragments is by providing more > "fixed points" around which discussions can range. The fixed points > are not immutable - they can evolve - but they're easy to point at, and > provide a definite manifestation of the topic at some stage of its life. That's a good point. Mailing list threads are great if you're around when they come up. After that, searching is doable, but not easy enough - witness that the same threads tend to come up for any list. One good quality of lists is that if you can tell your reader to organize threads, then the discussion is broken up and shoved in your face for you piece by piece. In a wiki, on the other hand, you have to return to the same page, find where you were last, and actively look for changes. > The dev.zope.org proposals site is one example where definite subjects are > at hand. As someone behind the WikiNG proposal, who *wants* to be able to > reap the suggestions and details from a discussion, but knows i won't have > the time for a while to actually concentrate attention on it, i dread > having to collect all the messages, for later review for harvesting. > Furthermore, messages on the mailling list tend to diverge more and > farther from the topic, than they do when placed within the wiki. > > What i'd like the best, for now, is to have discussion happen on the > mailling list *when someone wants to feel something out*, *and then > they're responsible for summarizing in the wiki discussion page, if they > have anything to harvest*. Note that we keep on acknowledging that the different fora are better in different ways, and that what we keep on wanting is the right way to communicate and propagate between the fora. Here, you want it to be easy to pop a thread into a wiki. Something like a thread-to-wiki feature would be nice - tell the wiki "flatten this thread & make a page for it", then edit it by hand. But it's still a one-way link, really, the best you can do is post a final message to the thread - 'see the wiki for further discussion'. Which isn't that bad, really. What I really want is for the different fora to just be interfaces on the information. I'm not sure how, it isn't that realistic, I can't think of an implementation without it getting overfeatured. Something like wiki edits being reflected in the mailing list archive. Nah. -- Karl Anderson karl(a)digicool.com

1 0

Re: [ZWeb] ZWN: HiperDom 0.1 is out
by Lalo Martins 02 Oct '00

02 Oct '00

On Mon, Oct 02, 2000 at 01:30:47PM -0700, Paul Everitt wrote: > > One thing you didn't mention on the pages -- requirements. It seems to > want something imported from sax -- does this mean Python 1.6/2.0? Does > it also require XMLDocument? Sorry, forgot that bit. It wants the whole library from Python's XML-SIG. Under Debian I installed this by requesting the package "python-xml" from apt. []s, |alo +---- -- Hack and Roll ( http://www.hackandroll.org ) News for, uh, whatever it is that we are. http://zope.gf.com.br/lalo mailto:lalo@hackandroll.org pgp key: http://zope.gf.com.br/lalo/pessoal/pgp Brazil of Darkness (RPG) --- http://zope.gf.com.br/BroDar

1 0

Hotfix_2000-10-02
by Shane Hathaway 02 Oct '00

02 Oct '00

http://www.zope.org/Products/Zope/Hotfix_2000-10-02/Hotfix_2000-10-02.tar.gz This hotfix addresses an important security issue that affects Zope versions 2.2.0, 2.2.1, and 2.2.2. It is sometimes possible to access, through a URL only, objects protected by a role which the user has in some context, but not in the context of the accessed object. Currently, the validate() method of all known user folder implementations validates against the users' roles in the context of PARENTS[0]. PARENTS[0] refers to the acquisition context of the object being published. All security checks, however, should check an object's containment, not its acquisition context. validate(), therefore, needs to verify the user's roles in the context of the object being published. This hotfix forces that to occur by temporarily leaving the object at PARENTS[0] then removing it after validation has been performed. Unfortunately, this is not an ideal correction. In the near future all user folder validate() implementations need to perform security checks using the new Zope security policy subsystem. Until that is completed, this hotfix should close the security problem. While we know of no instances of this issue being used to exploit a site, we recommend that any Zope 2.2.x site that is accessible by untrusted clients have this hotfix product installed to mitigate the issue. The hotfix will work for all versions of Zope 2.2.0 and higher. A future version of Zope will contain the fix for this issue, and you will be able to uninstall the hot fix after upgrading.

1 0

Back from the dead & xmlc
by Jason Spisak 02 Oct '00

02 Oct '00

Zope Devers, THis is going to seem strange coming from someone who hasn't been on the list in a long time, but I was at the Linux Expo in San Jose, and sat in on a Web app talk. Lutris was in charge of the panel, and they talked about xmlc. I went to their booth and asked about it. I think it could be the best way to get hard-core python people to jump on zope's band-wagon, and stop the dtml frowning. If you who are in the know about zope have time, please read a quick bit on what it is. http://xmlc.enhydra.org Especially the tutorial: http://staff.plugged.net.au/dwood/xmlc/index.html Is there any obvious reason why Zope wouldn't benefit tremendously from this design and programming separation and pure python boost? All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

6 21

Re: [Zope-dev] Re: CoreSessionTracking proposal
by Chris McDonough 02 Oct '00

02 Oct '00

I suppose I could implement something like this (encode the IP address into the token) and provide a knob to turn it on and off on the id manager. I'm not going to do this for the first iteration, I need to get it working first. :-) Steve Spicklemire wrote: > > I forget now where I saw this.... but one of the session managers I looked > at once checked the IP address of the visitor to make sure it was the > same for the entire session, or longer. This at least makes it much harder > to hijack a session, even though it means that long-lived cookies might > be fooled as a user gets a new dynamic IP address... > > -steve > > >>>>> "Chris" == Chris McDonough <chrism(a)digicool.com> writes: > > Chris> Session tokens, AFAICT, cannot be secured. They can only > Chris> be obfuscated, which mitigates the risk that they will be > Chris> guessed. However, there's no way to completely secure > Chris> them, no matter how many MD5 hashing algorithms you run on > Chris> them. If a session token is stolen, that's the key that > Chris> the "attacker" needs to visit the website "as you". I've > Chris> addressed this in the implementation by giving the session > Chris> token a random element, and this mitigates a guessing > Chris> attack, but not a theft attack. -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org

1 0

Re: [Zope-dev] mailing list 'noise'
by Karl Anderson 02 Oct '00

02 Oct '00

Ken Manheimer <klm(a)digicool.com> writes: > On Thu, 28 Sep 2000, Chris Withers wrote: > > > Toby Dickenson wrote: > > > I dont see this as a problem: You only create a new list when the > > > traffic for that proposal gets too great for zope-dev. Threading is > > > good enough before that point. > > > > Yes, but zope-dev has a relatively high traffic load... Why should you > > have to put up with all that 'noise' if you're only interested in posts > > for your comparatively small discussion? > > Yeah - maillists flow by, and not everyone can follow all the traffic all > the time!! The cool thing about "content-based" mailling lists, where > people can subscribe to notifications about changes in subthreads, is that > you just subscribe to the part of the discussion that has your interests!! I haven't understood this gripe ever since I started reading mail with Gnus. Before anyone groans, I'm not sure that Gnus is ready for general use by anyone who doesn't want to learn elisp - but surely there's anther reader with these features? The point that I'm trying to make is that a mailing list has all the strucure needed to keep abreast of an important thread. I don't think it's perfect when you can't afford to miss a single important article, but it works great for general lists. Gnus treats mail & news as the same, and allows you to score posters, threads, messages, etc. both manually and adaptively. Threads can be presented by order of their score. Adaptive scoring is what really makes it work. The normal reading commands - read article, kill thread, save article, catchup (mark unread articles as read) can affect the scores. So, reading articles in a thread tends to make it float to the top, and posters who contribute to well-read threads elevate future threads that they contribute to. The inverse for killed threads, less so for caught up threads. I can read comp.lang.python when it has 3000 unread articles, by skimming 100-500 articles, reading some, catching up or killing the rest, and saving other 2500 for later. I draw in what I'm interested in from the mass of unread articles first, each time, and the stuff that I rarely get around to is the stuff that I don't miss. Same with rec.bicycles.soc - when the article count gets to 200-300, I read the 2-10 articles that I'm probably interested in, and miss the 95% which is almost always noise. That's why I resist moving to other fora. I've never seen one that lets me use better tools. Okay, my download finished while I wrote this, back to work :) -- Karl Anderson karl(a)digicool.com

4 4

Re: [Zope-dev] CoreSessionTracking proposal
by Chris McDonough 01 Oct '00

01 Oct '00

"Phillip J. Eby" wrote: > > At 10:44 PM 9/30/00 -0400, Chris McDonough wrote: > > <snip session token description> > > Huh? I don't get it. It's still just an opaque key from the POV of the > session data managers, right? Yes. The only difference is that the actual string placed into the cookie or read via URL-rewriting. This is no longer just the browser id and a random element. It's a combination of the browser id (browser key), and a "session key" as well as a random element. When the session id manager is asked for the browser id by the session id manager, it returns it, same as before -- session data managers may still base their data object keys on browser ids. However, they may alternately base their data object keys on the combination of the session key component and the browser key component if they desire. The biggest change is that the actual value of the opaque string that is the *token itself* is not the key used by session data managers to represent session data object ids. Instead, the token is decomposed and session data managers ask for either the opaque string which represents the browser key - OR - they ask for the opaque string which represents a session key/browser key combination. As they choose, session data managers may base their data object keys on either of these values. (see below for rationale) > >it could be handled internally, but I've > >decided to put the "session" state on the client instead, it's easier). > > I'm still lost. Reluctance to store what state? Why do you need to store > anything? In the original implementation, the token was composed of a browserid and a random element. No timeout was imposed upon the browser id (except possibly for a cookie timeout), and the "browser id manager" had no concept of any timeout whatsoever. Session data managers handled all expiry of objects related to a browser id. A browser id never expired, but data objects related to a browserid managed by session data managers did. In the new implementation, it's much the same. Except the token is composed of a browser key (browserid), a "session key" (which is a timestamp), and a random element. The browser key component of the token stays constant for as long as the conveyance mechanism allows as decided by the site manager. The session key component changes when the sessionid manager session key timeout is reached for the browser that sends the token. The token is recomposed when the session key component changes. This means that if you're using cookies, the cookie will be reset when the global session id manager timeout is reached. If you're using URL-rewriting, the token will be changed in the URL representation. The state that is being stored on the client in the new implementation (that was not stored in the old) is the session key "expires" time. It's encoded into the session key component of the token (currently it *is* the session key). This could alternately be done in a dictionary managed by the session id manager stored on the server which related a browserid to a session "expires" time. I chose to do it the former way. However, there is no forced coupling between session data managers and the token composition algorithm. Session data managers may use either the browserkey string or the combination sessionkey/browserkey string as object keys as they see fit. > Keep in mind that a session data manager just throws away its > record for a given ID when it wants to expire it. If the user "comes back" > and still has a session cookie, that particular session data manager will > just start a new session with the old key. No harm, no foul. Nothing has changed here. What I'm describing is purely an implementation detail to accomodate the "synchronization" of session boundaries between session data managers. I think you're getting caught up in the fact that the actual token value is changing, which means nothing, as the values its decomposed into have all the properties of the old implementation. <snip> > As for associating sessions between two session data managers, why can't > the simple session cookie concept handle that? It's only one ID, and so is > shared, right? I'm not quite clear on what the requirement is here. Let's dissociate the cookie value from the stuff it represents (additionally... for the benefit of other folks here, the token need not be sent via a cookie, it could be part of a URL or some other conveyance mechanism). The session id manager handles the details of what goes in the token, and handles the details of decomposing the token into its component values. In the end, after the token has been decomposed, we're left with a "browser key" and a "session key" as well as a random component. Most session data manager implementations will ask for the browser key, and will ignore the session key. This usage is analogous to what is outlined currently in the use cases at CoreSessionTracking. However, some data manager implementations will rely on the combination of the browser key and the session key, notably in cases where *literal* "session-tracking" is a requirement. The requirement outlined in the jam session is a situation where it's desirable to keep session data managers' "session" boundaries in lockstep with each other. For example, if CDNow starts to use Zope, perhaps their internal structure requires one session data manager for the CD portion of the site and one for the DVD portion of the site. If each session data manager had its own decentralized idea about session data object expiry (e.g. if they only used the browser id component of the session token), there would be no way to correlate the data between the actual *sessions* represented by the session data objects. It would only be possible to correlate data between the *browsers* represented by the session data objects. Many marketing folks want to know what the heck happens *down to the visit* when folks use their site. CDNow would want to know what happened during user X's session (one discrete visit), and they would want some way to correlate the information represented by the CD site session data objects and the information represented by the DVD session data objects for a particular visit. The session data objects managed by each session data manager would be persistent, and the ids of the session data objects kept within both would be represented by the combination of a session key and the browser key. The ids of objects managed by one session data manager would be potentially identical to the ids of objects managed by another, and they refer to *sessions* and not *browser ids*. This allows CDNow to accurately and easily correlate the objects managed by each session data manager with each other by implementing and instantiating two session data managers that make use of the session key component of the session token as a part of their session data object keys. > >This will be an opt-in feature for session data manager implementations, > > Now I'm really lost. What does the feature have to do with the session > data managers at all? I hope I've explained this more clearly above... > I think you're actually making things more complex than they need to be. > It sounds like the misunderstanding probably stems from the part of the > SessionIDManager Wiki page that reads: > > "Session ID's provided by a Session ID Manager never expire. The cookie may > expire, or data associated with the session may expire, but the session ID > never does. It can be thought of as being like a "browser serial number" > that sometimes changes (when a cookie expires, or user reloads a > non-session URL in URL mode)." IMHO, I'm making thing as complex as they need to be, but no more, and I don't think there's any misunderstanding. FWIW, I think the requirement which I'm making the change for blows chunks. :-) <snip> > There are a few things that can also be done to shore up the security. > One, of course, is that session ID's should be hard to guess. And, it > should be possible to specify to the SessionIDManager that "secure" cookies > (HTTPS only) are required. 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 harder to guess? -- Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org

2 3

Re: [Zope-dev] CoreSessionTracking proposal
by Dieter Maurer 01 Oct '00

01 Oct '00

Phillip J. Eby writes: > At 09:27 PM 9/30/00 +0200, Dieter Maurer wrote: > > * I am *VERY* suspicious whenever I get > > a cookie with an expiration date more than > > a few days in the future. > > > > If Zope tries to implement long living browser ids, > > I fear, Zope sites will have a high chance, I will > > no longer visit them. > > 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 expiration date, and which therefore only live so long as > the user's browser is open, be it minutes or days. I would be very happy with this. > > * I do not think "Annonymous" should have > > "Access Session Data" permission > > with the exception to its own session data. > > As I understand it, the "Access Session Data" permission gives you the > right to call a method that returns you the session data for the current > request, but does not give you the right to access arbitrary session data. > Thus, one only has permission to see one's own session data. Do we need a special permission for this? All users will have it (when sessions are used at all). Thus, why clutter the (already cluttered) security management screen with an additional permission. > > Again, session handling should be transparent, > > implemented by a mechanism that implements > > its own special purpose access policy > > (access to session data only by the > > session owner). > > No such policy is necessary, since access to the session data objects > themselves is gated. You can't get to the session object unless you have > management rights on the session data manager itself, or if the session > data object is for "your" session -- the session for the current REQUEST. That's precisely the special policy, I speak of. Dieter

2 1

CoreSessionTracking proposal
by Dieter Maurer 01 Oct '00

01 Oct '00

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 longer than, say, a day. * I am *VERY* suspicious whenever I get a cookie with an expiration date more than a few days in the future. I do not see any reason why a site should be able to track my activity over a longer period of time -- at least no without my explicit consent. I tend to refuse long living cookies and as sites continue to send cookies on any request, I disable cookies all together. If this means, a site can not be visited, I stop visiting the site. If Zope tries to implement long living browser ids, I fear, Zope sites will have a high chance, I will no longer visit them. Security: * I do not think "Annonymous" should have the permission "Add Session Data Objects". Session handling should be transparent, including allocation of a session data object. * I do not think "Annonymous" should have "Access Session Data" permission with the exception to its own session data. Sessions may contain confident information that must not be revealed to other users. Again, session handling should be transparent, implemented by a mechanism that implements its own special purpose access policy (access to session data only by the session owner). Consistency: * sometimes "__zsession__" and sometime "_ZopeId" seems to be used to refer to an identifier used for session tracking * how is it possible to have nested "Session ID Managers" (necessary for delegation) with "getZopeSessionID" a singleton? As I understand it, the "singleton" property prevents any child to reimplement the method. I must be wrong with this assumption. Dieter

3 6

Re: [Zope-dev] mailing list 'noise'
by Simon Michael 01 Oct '00

01 Oct '00

"Rik Hoekstra" <rik.hoekstra(a)inghist.nl> writes: > I think everyone agees about that, but at least some of the participants in > this discussion also agree that most of the existing discussion tools for > any mode of discussion are frustrating and insufficient at times. Moreover, > apparently not everyone favours the same mode of discussion and this alone > would be more than enough justification for a product that would cater > different modes of discussion _at_the_same_time_. Hear hear!

1 0