Re: [Zope3-dev] Certification: Support platforms different from Linux?
Hi, Am Mittwoch, den 14.12.2005, 10:47 -0500 schrieb Jim Fulton: Yes. The customers of ours most likely to care about this use Windows. I would say in general, for better or worse, the decision makers who would care about CC would also care about Windows. I suspect that the decision makers who care about linux would me likely to understand that the platform doesn't matter that much and that certification for Windows should make them feel warm and fuzzy about their Linux installations. I'm including Windows and Linux for now. I wonder whether we should (for ourselves) guess which version we might want to stick to. Linux might be less of a problem as Windows. Would it be Windows 2000 Server or Windows 2003 Server? BTW: I just read that the current Windows line (2k3 and XP IIRC) was certified for CC lately. Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/testbrowser/ fix bug caused be impedance mis-match between Mechanize and zope.testbrowser
Benji York wrote: Two of the three lines of _quote are comments about why the method exists, is there something that you'd like added? Perhaps it shouldn't be a method at all, but refactored to be inline (with comments). Inline would be the way I'd go, as it'll stop people (mis)using the method in future... That, specifically, wouldn't work, but no matter; the RFC is pretty clear that there can be no more than 2 space characters in the first line of the request, so I don't really think anything different should be done. Yup, glad someone has the patience to wade through RFC's :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Hi, within the certification we once created a list (drawn from the CC catalogue) of functionality we want to support. One of those is called Residual Information Protection (RIP) The meaning of RIP is that when you delete security attributes (roles, users, groups, permission grants/denials) you want to make sure that the overall consistency of your security attributes is not affected. Example: Bob is a user of your site with the login name bob. He was granted permissions all over the place, for example in folder /asdf he has the permission perm.ModifyObjects. Bob doesn't want to work with you anymore and tells you so. You delete the user account bob from the system. 2 years later. Another Bob arrives and you assign him the same username. Suddenly he has all the permissions that the original bob had. This is a simple example of what can happen when you only partially delete security attributes. And it is a known problem with todays Zope 2 security. Two questions arise for me now, as I face implementing the effective removal of residual data: - Does anybody know/understand whether this will heavily collide with undoing transactions or not? - Is there an efficient way on the application-level in Zope 3 to iterate over objects out of the database? (There is something in the ZODB IIRC that can support iterating over objects of the same class) Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Hi Christian interesting question! This is really a missing part in Zope3. Hi, within the certification we once created a list (drawn from the CC catalogue) of functionality we want to support. One of those is called Residual Information Protection (RIP) The meaning of RIP is that when you delete security attributes (roles, users, groups, permission grants/denials) you want to make sure that the overall consistency of your security attributes is not affected. Example: Bob is a user of your site with the login name bob. He was granted permissions all over the place, for example in folder /asdf he has the permission perm.ModifyObjects. Bob doesn't want to work with you anymore and tells you so. You delete the user account bob from the system. 2 years later. Another Bob arrives and you assign him the same username. Suddenly he has all the permissions that the original bob had. This is a simple example of what can happen when you only partially delete security attributes. And it is a known problem with todays Zope 2 security. Yes, that is excatly what we d right now. If we remova a principal we don't delete the permssion/grant imformation in the annotation. I guess we have to add a generic subscriber for this and cleanup all grant information in the object's annotation. Two questions arise for me now, as I face implementing the effective removal of residual data: - Does anybody know/understand whether this will heavily collide with undoing transactions or not? You mean if a principal get added back via the undoing transaction or if there is a meachnism to not allow to undo principal removal? - Is there an efficient way on the application-level in Zope 3 to iterate over objects out of the database? (There is something in the ZODB IIRC that can support iterating over objects of the same class) Do you mean if sombody uses a SQL DB backend or something like that? If so, I guess they have to provide the sublocation implementation as well. I have no idea if this is supported in SQL implementation like the SQLObject etc. Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. We do this everytime we delete a object. This is done with subscribers and dispatching events to sublocations if a ObjectRemoveEvent get fired. The only part we have to add is a subscriber which will remove grant information for sublocations. We have to use a little hook for this implementation since the content data structure isn't directly a child of the IAuthentication utility. Hm, perhaps we have to add a special event inherited from ObjectRemoveEvent and dispatch this event to sublocations of the ISite reather then to the sublocations of the IAuthentication. A different event will make sure that we not directly dispatch the original ObjetRemoveEvent to the content objects of ISite. Are I'm correct or did I miss something? Regards Roger Ineichen Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Hi, Am Freitag, den 16.12.2005, 11:14 +0100 schrieb Roger Ineichen: This is a simple example of what can happen when you only partially delete security attributes. And it is a known problem with todays Zope 2 security. Yes, that is excatly what we d right now. If we remova a principal we don't delete the permssion/grant imformation in the annotation. That's what my understanding about the current situation was as well. I guess we have to add a generic subscriber for this and cleanup all grant information in the object's annotation. That leads me to the question of local event subscribers ... Do they exist? Two questions arise for me now, as I face implementing the effective removal of residual data: - Does anybody know/understand whether this will heavily collide with undoing transactions or not? You mean if a principal get added back via the undoing transaction or if there is a meachnism to not allow to undo principal removal? I mean to make sure that the set of data that can be retrieved by undoing something doesn't make the system inconsistent. Example: - bob still exists. - bob is granted the permission perm.Modify on the object /asdf/b. - b gets deleted. - bob gets deleted, RIP comes in and removes all referenced permission grants - The deletion of /asdf/b gets undone. - The user bob is re-added. This could be handled by making sure that when something is undone, all the security attributes are valid. But I can give you an example that is even worse: - bob exists and is granted perm.Modify an the object /asdf/b - /asdf/b is deleted - bob is deleted and RIP is effective - bob get's readded - The deletion of /asdf/b gets undone. Now. At the point of making the deletion of /asdf/b undone will not be able to know that bob is a different bob then the one that existed before deleting it. :( Looks like we would have to introduce (globally) unique identifiers for users that are non-repeatable. - Is there an efficient way on the application-level in Zope 3 to iterate over objects out of the database? (There is something in the ZODB IIRC that can support iterating over objects of the same class) Do you mean if sombody uses a SQL DB backend or something like that? If so, I guess they have to provide the sublocation implementation as well. I have no idea if this is supported in SQL implementation like the SQLObject Nope. I thought about something to use if local event subscribers don't exist. Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. We do this everytime we delete a object. This is done with subscribers and dispatching events to sublocations if a ObjectRemoveEvent get fired. The only part we have to add is a subscriber which will remove grant information for sublocations. We have to use a little hook for this implementation since the content data structure isn't directly a child of the IAuthentication utility. Hm, perhaps we have to add a special event inherited from ObjectRemoveEvent and dispatch this event to sublocations of the ISite reather then to the sublocations of the IAuthentication. A different event will make sure that we not directly dispatch the original ObjetRemoveEvent to the content objects of ISite. Are I'm correct or did I miss something? Sounds like you understood my request very well. Regarding the implementation, I might need a small hint about the (sub-)location issues ... Cheers, Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?
Jeff Shell wrote: On 12/15/05, Martijn Faassen [EMAIL PROTECTED] wrote: [snip] One troublesome scenario I can imagine is that if I make my total skin in Zope 3.n, it works, and then Zope 3.n + 1 is released and it has a more specific view registered for some content object that I'm using. I was relying on having skinned the more general interface, but suddenly in Zope 3.n + 1 I get the Zope 3 view. That'd be bad. So, I'm not sure whether or not this ability is compromised in practice with this bugfix... If it is compromised, it may be bad design on your part? That's the decision that I came to. If it's truly the case that this is due to bad design, then that's good to hear. You obviously have more experience with this problem than I do, I'm just leaping into this thread with vague concerns. [snip details] I'm still unsure about how I feel about this situation in my gut. The Zope 3.1 way felt strangely intuitive, but I recognize why it was incorrect and why the 3.2 implementation does what it does. [snip] For us at Bottlerocket, these core objects have bitten us in the past. So for me - and I'm not saying it applies for you or anyone else - this change to the 'correct' behavior for multi-adapter lookup has highlighted some design flaws in our code and way of thinking. If this issue didn't show itself now, a different issue may have shown up in the future. Okay, we'll see whether this turns up any flaws in the DocumentLibrary in this department; we haven't tried it with Zope 3.2 yet. It's good to hear your conclusion that this is essentially the right behavior, though the counterintuitiveness Thanks for the debug module, I'll tuck it away somewhere! Might be useful to put this somewhere under svn.zope.org or something, by the way. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Roger Ineichen wrote: [Christian] Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. We do this everytime we delete a object. This is done with subscribers and dispatching events to sublocations if a ObjectRemoveEvent get fired. Wouldn't this still be a performance killer? I.e. if a user gets removed in a large site, wouldn't an event need to be sent to all objects that have security annotations in the tree? And at the end, a large transaction, or a lot of transactions, would need to be committed. From my experience with Zope 2, this sounds like a potentially very expensive operation, right? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Heads up, adapter-registry refactoring (was Re: [Zope3-dev] Re: View lookup changes in Zope 3.2?)
I'm hoping to redo the internal details of a adapter registries in the next release cycle, along the lines of work done in the jim-adapter-redesign branch. This redesign has the following goals: - Bring the adapter-lookup algorithm closer to the somewhat familiar method-lookup algorithm for Python new-style classes. Of course, this is extended (in an ovious way) to deal with multiple dispatch. This new algorithm should give the same results as the current mechanism. In fact, I delayed working on the multi-adapter fix, hoping that I would achiev the same result with the new lookup mechansim. - Provide an equivalent to super for adapter lookup. If an adapter overrides another adapter, it should be possible for the overriding adapter to find and use the adapter it overrides. - Provide greater performance. I had originally hoped to achive the last goal without use of any caching. (The current algorithim is based on very extensive caching.) Alas, without caching the new algorthm is too slow, and much slower than the existing alsgorthm. I am hopeful that with a much simpler and less expensive cache in front of the new algorthm, I'll be able to meet current performance for single-adapter lookup and greatly improve performance for multi-adapter lookup. I expect to be able to report results in January. Obviously, this refactoring will render obsolete tools writted against the current implementation. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Am Freitag, den 16.12.2005, 12:52 +0100 schrieb Martijn Faassen: Roger Ineichen wrote: [Christian] Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. We do this everytime we delete a object. This is done with subscribers and dispatching events to sublocations if a ObjectRemoveEvent get fired. Wouldn't this still be a performance killer? I.e. if a user gets removed in a large site, wouldn't an event need to be sent to all objects that have security annotations in the tree? And at the end, a large transaction, or a lot of transactions, would need to be committed. From my experience with Zope 2, this sounds like a potentially very expensive operation, right? Right. -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Certification: SupportingResidual InformationProtection in Zope 3
Hi Martijn [...] [Christian] Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. We do this everytime we delete a object. This is done with subscribers and dispatching events to sublocations if a ObjectRemoveEvent get fired. Wouldn't this still be a performance killer? I.e. if a user gets removed in a large site, wouldn't an event need to be sent to all objects that have security annotations in the tree? And at the end, a large transaction, or a lot of transactions, would need to be committed. From my experience with Zope 2, this sounds like a potentially very expensive operation, right? Yes you are right. Do you have another idea? How about to add a concept like intid? We could add objects where contain annotated security info to a utility. This allows us to get the right objects from this utility and avoid traversing a structure. Regards Roger Ineichen Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Christian Theune wrote: Hi, within the certification we once created a list (drawn from the CC catalogue) of functionality we want to support. One of those is called Residual Information Protection (RIP) The meaning of RIP is that when you delete security attributes (roles, users, groups, permission grants/denials) you want to make sure that the overall consistency of your security attributes is not affected. Example: Bob is a user of your site with the login name bob. He was granted permissions all over the place, for example in folder /asdf he has the permission perm.ModifyObjects. Bob doesn't want to work with you anymore and tells you so. You delete the user account bob from the system. 2 years later. Another Bob arrives and you assign him the same username. Suddenly he has all the permissions that the original bob had. This is a simple example of what can happen when you only partially delete security attributes. And it is a known problem with todays Zope 2 security. This is only a problem if username === user id. In both Zope 2 and Zope 3, these are distinct, although this isn't widely recognized or leveraged in Zope 2. I don't think it is necessary to remove all grants to an old user *id* as long as ids are never reused. I'd say it might even be useful to keep the old grants, at least for some period, for auditing purposed. If we *do* need to be able to remove all grants for a deleted user when we remove a user, then we need to provide an authorization system that makes this possible. Two questions arise for me now, as I face implementing the effective removal of residual data: - Does anybody know/understand whether this will heavily collide with undoing transactions or not? It would. The Undo feature should not be included in the CC certified version, or, perhaps undo should only be exposed to adminstrators as a break glass sort of feature. The reason is that, for current versions of ZODB, undo cannot maintain transactional integrity. - Is there an efficient way on the application-level in Zope 3 to iterate over objects out of the database? (There is something in the ZODB IIRC that can support iterating over objects of the same class) Otherwise this function is likely to become a performance killer, as I'd have to go all over the place to remove stuff. By definition, there is no efficient way to iterate over all objects in a database, any database, unless the database is small. If we need to be able to do this, we should design support into the authorization system that we certify. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual InformationProtection in Zope 3
Christian Theune wrote: ... I guess we have to add a generic subscriber for this and cleanup all grant information in the object's annotation. That leads me to the question of local event subscribers ... Do they exist? No. I don't see why you need them here. You don't need a local subscriber to provide a local effect. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Hi, Am Freitag, den 16.12.2005, 07:16 -0500 schrieb Jim Fulton: This is only a problem if username === user id. In both Zope 2 and Zope 3, these are distinct, although this isn't widely recognized or leveraged in Zope 2. I don't think it is necessary to remove all grants to an old user *id* as long as ids are never reused. I'd say it might even be useful to keep the old grants, at least for some period, for auditing purposed. If we *do* need to be able to remove all grants for a deleted user when we remove a user, then we need to provide an authorization system that makes this possible. I think if we can guarantee never to reuse a user id, provide a tool for doing RIP and we do not provide undo we are fine. By definition, there is no efficient way to iterate over all objects in a database, any database, unless the database is small. If we need to be able to do this, we should design support into the authorization system that we certify. Agreed. This would mean that the authorization system (which is policy dependant if I understand it correctly) will have to maintain data structures that allow efficient handling for those tasks. Right? Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Jim Fulton wrote: ... If we need to be able to do this, we should design support into the authorization system that we certify. I'll note that this implies that the grants are stored centrally. There are a number of reasons why this might be beneficial. It's interesting to note that on Unix systems, it is not too terribly expensive (though not cheap) to change security information on a large tree. (I'd guess the same is true on Windows, probably for similar reasons.) This is because the information is stored in inodes, rather than in the files themselves. The actual files don't need to be open and read. In our current annotation-based approach, we have to load an object to get it's grant annotation. A pet project of mine that I'm dying to work on, but fear I won't have time for, is to add optional support for managing security information in ZODB. A storage that supports object security would maintain extra information, accessable as additional persistent objects, that maintain lists of principal grants for each object. A grant for a principal for an object would be a triple of boolean values for read, write, and ownership, where you would need the ownership to change the grants. Of course, the storage would use this information to mediate access. The main goal of this would be to make ZEO a much more viable protocol for client-server applications. I also think that the flexible permission scheme I introduced to Zope was a huge mistake. A security system that people don't understand is insecure. A corrolary of this is that complex security systems are not secure. I wish I knew more (had time to read literature) about usable security systems. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Hi, Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton: Christian Theune wrote: I think if we can guarantee never to reuse a user id, provide a tool for doing RIP and we do not provide undo we are fine. Only if we manage the user ids. We often get principal ids from outside sources. In fact, we usually do this in production. In the case when we're using an external principal soure, we also don't autmatically know when the principal is removed. Also, current principal-management facilities in Zope 3 allow managers to pick ids. We probably would need to curtail this or at least prevent reuse. It's probably not wise to rely on this. That sounds like for a usable certified system RIP might be out of scope? Hmm. Hope not. Right. The security policy is part of the authorization system. The authorization system, or at least a CC-complient authorization system should probably grow a principal-removal API. Well. If that would be an authorization system that would not be helpful in everyday business, then growing one only for CC would be beside the point of the certification to assure people that the system they use on a daily basis matches their security expectations. Christian -- gocept gmbh co. kg - schalaunische str. 6 - 06366 koethen - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 - fax +49 3496 30 99 118 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: Supporting Residual Information Protection in Zope 3
Christian Theune wrote: Hi, Am Freitag, den 16.12.2005, 07:49 -0500 schrieb Jim Fulton: Christian Theune wrote: I think if we can guarantee never to reuse a user id, provide a tool for doing RIP and we do not provide undo we are fine. Only if we manage the user ids. We often get principal ids from outside sources. In fact, we usually do this in production. In the case when we're using an external principal soure, we also don't autmatically know when the principal is removed. Also, current principal-management facilities in Zope 3 allow managers to pick ids. We probably would need to curtail this or at least prevent reuse. It's probably not wise to rely on this. That sounds like for a usable certified system RIP might be out of scope? Hmm. Hope not. There could be a UI for removing principal grants that a manager could use to remove grants after a principal has been removed externally. Right. The security policy is part of the authorization system. The authorization system, or at least a CC-complient authorization system should probably grow a principal-removal API. Well. If that would be an authorization system that would not be helpful in everyday business, then growing one only for CC would be beside the point of the certification to assure people that the system they use on a daily basis matches their security expectations. I'm not conviced that this is an every-day requirement. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Certification: SupportingResidual InformationProtection in Zope 3
Roger Ineichen wrote: [Martijn goes into why this might be slow] Yes you are right. Do you have another idea? A fairly drastic one, unfortunately -- catalog all role and permission assignments and run a query as soon a user is removed. Hm, perhaps another idea would involve the timestamp of creation in the userid somewhere, to make the ids unique. Unfortunately I don't see how that would work with external authentication systems such as LDAP, as we don't know when userids are created and removed there. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Certification: SupportingResidual InformationProtection in Zope 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Roger Ineichen wrote: [Martijn goes into why this might be slow] Yes you are right. Do you have another idea? A fairly drastic one, unfortunately -- catalog all role and permission assignments and run a query as soon a user is removed. CMF does this for local roles, and Jim is already on record as disliking it. I am pleased with the *result*, which also allows the catalog to filter normal content results efficiently based on the user's roles (the original eason for the index). OTOH, the *implementation* is grotty. Hm, perhaps another idea would involve the timestamp of creation in the userid somewhere, to make the ids unique. Unfortunately I don't see how that would work with external authentication systems such as LDAP, as we don't know when userids are created and removed there. The actual ID used by LDAP is a DSN. Perhaps the authorization system could map the DSNs to internally-generated integer ID, which would be the only value actually stored in grant records. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDotJc+gerLs4ltQ4RAscQAJ9pNpD2Dce+3vxbOKOu3jeyi4OcZgCg08Ss uLAalHjZ6RTaj32kmTnJLrw= =J37w -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Certification: SupportingResidual InformationProtection in Zope 3
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Roger Ineichen wrote: [Martijn goes into why this might be slow] Yes you are right. Do you have another idea? A fairly drastic one, unfortunately -- catalog all role and permission assignments and run a query as soon a user is removed. CMF does this for local roles, and Jim is already on record as disliking it. I am pleased with the *result*, which also allows the catalog to filter normal content results efficiently based on the user's roles (the original eason for the index). OTOH, the *implementation* is grotty. I don't like the use case very much, but accept that it is valid. You convinced me one day that this doesn't have to be so bad, especially if most grants are to groups/roles. (I've abandoned using roles as a principal grouping mechanism, but that's a different topic.) In any case, that's a different data structure than what we need here. Here, I think the best solution is for the authorization system to store grants in a centralized data structure of it's own. This data structure would be optimized for it's own purposes, not for document searching. These two use cases want different data structures. Hm, perhaps another idea would involve the timestamp of creation in the userid somewhere, to make the ids unique. Unfortunately I don't see how that would work with external authentication systems such as LDAP, as we don't know when userids are created and removed there. The actual ID used by LDAP is a DSN. Perhaps the authorization system could map the DSNs to internally-generated integer ID, which would be the only value actually stored in grant records. Isn't a dsn a string? That's all we require of a principal id. What advantage would an integer provide? In any case, we are left with a more basic problems: - Someone could be removed from an external user source without Zope being aware of it. - An external system could remove a principal and reused the id for a new principal -- again without Zope being aware of it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in zope.testing trunk Windows 2000 zc-bbwin
The Buildbot has detected a failed build of zope.testing trunk Windows 2000 zc-bbwin. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2258 Blamelist: andreasjung,ctheune,hdima,jim,jinty,jmo,sidnei,tim_one,tseaver,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches Zope-3.1 2.4 Windows 2000 zc-bbwin
The Buildbot has detected a failed build of Zope3 branches Zope-3.1 2.4 Windows 2000 zc-bbwin. Buildbot URL: http://buildbot.zope.org/ Build Reason: The web-page 'force build' button was pressed by '': Build Source Stamp: None Blamelist: BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux zc-buildbot
[Tim Peters, on the testRunIgnoresParentSignals failure] That's definitely the problem here, and is easy to reproduce by inserting a short time.sleep() inside os.rmtree(): Should have said shutil.rmtree(); anyway: I'll try to fix it later today if I can make time, and nobody else does first ... I did that yesterday, and ran the test hundreds of times after w/o problems. Yesterday and today, in spare moments I stitched rev 40792 of zdaemon into: Zope trunk Zope 2.9 branch Zope3 trunk Zope3 3.2 branch I _ think_ that covers all the places that need it for now. If anyone knows of another place (I have lazier plans to update ZODB ;-)), be my guest. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Linux remy
The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 Linux remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2277 Blamelist: tim_one BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Linux remy
The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 Linux remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2278 Blamelist: jim BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
zope.i18n.format pytz usage (was Re: [Zope3-dev] XXX Roundup)
On Dec 16, 2005, at 4:20 PM, Benji York wrote:
Gary zope/i18n/format.py:141 and 149
Yup: the pytz StaticTzInfo is being used in a non-API way, and while
pickling works, unpickling doesn't (ew!).
Here's the interactive prompt example, if anyone cares.
import pytz.tzinfo
tz = pytz.tzinfo.StaticTzInfo()
import pickle
import datetime
delta = datetime.timedelta(hours=-5)
delta
datetime.timedelta(-1, 68400)
tz._utcoffset = delta
pickle.dumps(tz)
'cpytz\n_p\np0\n(Ntp1\nRp2\n.'
pickle.loads(pickle.dumps(tz))
Traceback (most recent call last):
File stdin, line 1, in ?
File /home/gary/z4i/var/opt/python/lib/python2.4/pickle.py, line
1394, in loads
return Unpickler(file).load()
File /home/gary/z4i/var/opt/python/lib/python2.4/pickle.py, line
872, in load
dispatch[key](self)
File /home/gary/z4i/var/opt/python/lib/python2.4/pickle.py, line
1153, in load_reduce
value = func(*args)
File /home/gary/z4i/var/src/zope3/src/pytz/__init__.py, line
163, in _p
return unpickler(*args)
File /home/gary/z4i/var/src/zope3/src/pytz/tzinfo.py, line 340,
in unpicklertz = pytz.timezone(zone)
File /home/gary/z4i/var/src/zope3/src/pytz/__init__.py, line 47,
in timezonezone = _munge_zone(zone)
File /home/gary/z4i/var/src/zope3/src/pytz/__init__.py, line 71,
in _munge_zone
return zone.replace('+', '_plus_').replace('-', '_minus_')
AttributeError: 'NoneType' object has no attribute 'replace'
This is not pytz's fault: it wasn't designed to work the way that the
format module is using it, as Stuart points out following Philipp's
'XXX'.
I think I can fix it by using the pytz.reference.FixedOffset class.
That's what I'll try to do now.
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: zope.i18n.format pytz usage (was Re: [Zope3-dev] XXX Roundup)
On Dec 16, 2005, at 4:56 PM, Gary Poster wrote: ... I think I can fix it by using the pytz.reference.FixedOffset class. That's what I'll try to do now. BTW, let me note that this is still bad. These things *should not* be persisted: they will generate lots and lots of little instances. Maybe the code should use a class that refuses to be persisted instead. Another approach would be to copy over zope.app.datetimeutils into zope.i18n: it has already addressed the problem. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Linux remy
The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 Linux remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2281 Blamelist: jim BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Linux remy
Tim Peters wrote: I hesitate to suggest that the buildbot run with -vv too, but it sure would have saved Jim and me time in this case. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 branches 3.2 2.4 Linux remy
The Buildbot has detected a failed build of Zope3 branches 3.2 2.4 Linux remy. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 2282 Blamelist: jim BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
