Re: [Zope-dev] Traversal issue which affects Five
On 8/20/06, Alec Mitchell [EMAIL PROTECTED] wrote: On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote: ... In our local Zope version, I implemented a solution that is (in my opinion) superior: Define an exception UseTraversalDefault that can be used by __bobo_traverse__ to tell the traversal process (either URL traversal in the publisher or restricted/unrestricted/CMF traversal) to use the default lookup. One big advantage is that e.g. Archetypes.BaseObject.BaseObject.__bobo_traverse__ no longer need this horrible dance to decide whether it should or must not create a NullResource. OK, I'm bringing an old thread back to life to propose implementing this change for Zope 2.10. It would be quite nice to get rid of this horrible dance in the next version of Archetypes, and the change would generally allow people to make simpler __bobo_traverse__ methods that don't have to reimplement the traversal machinery themselves, especially since the traversal machinery is a bit in flux these days. Of course, if the plan is to make __bobo_traverse__ obsolete in the near future (provided reasonable alternatives exist), then making it nicer shouldn't really be too much of a priority. Thoughts? Well, as I mentioned in April, i was going to in Zope 2.10 refactor this and get rid of five:traversable, so I asked for specific usecases so I could test it. No use cases popped up and the refactoring is now finished. What effect that has on your usecase I don't know. However, five objects no longer have a __bobo_traverse__ by default, which should make things simpler. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
On 8/21/06, Lennart Regebro [EMAIL PROTECTED] wrote: On 8/20/06, Alec Mitchell [EMAIL PROTECTED] wrote: On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote: ... In our local Zope version, I implemented a solution that is (in my opinion) superior: Define an exception UseTraversalDefault that can be used by __bobo_traverse__ to tell the traversal process (either URL traversal in the publisher or restricted/unrestricted/CMF traversal) to use the default lookup. One big advantage is that e.g. Archetypes.BaseObject.BaseObject.__bobo_traverse__ no longer need this horrible dance to decide whether it should or must not create a NullResource. OK, I'm bringing an old thread back to life to propose implementing this change for Zope 2.10. It would be quite nice to get rid of this horrible dance in the next version of Archetypes, and the change would generally allow people to make simpler __bobo_traverse__ methods that don't have to reimplement the traversal machinery themselves, especially since the traversal machinery is a bit in flux these days. Of course, if the plan is to make __bobo_traverse__ obsolete in the near future (provided reasonable alternatives exist), then making it nicer shouldn't really be too much of a priority. Thoughts? Well, as I mentioned in April, i was going to in Zope 2.10 refactor this and get rid of five:traversable, so I asked for specific usecases so I could test it. No use cases popped up and the refactoring is now finished. What effect that has on your usecase I don't know. However, five objects no longer have a __bobo_traverse__ by default, which should make things simpler. Indeed it does, the issue is that writing __bobo_traverse__ methods which try to fallback on the normal traversal mechanisms has always been a pain (you have to reimplement the normal traversal mechanisms yourself, including some funny WebDAVisms). If instead the __bobo_traverse__ mechanism could explicitly tell its caller (via an exception) to continue with the standard traversal, it would be a nice improvement. Of course, the real fix may be for products to stop using __bobo_traverse__ and start sing BeforeTraverseEvent subscribers, or IPublshTraverse adapters. This is something I hope to look into in the next couple days. Alec ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
On 8/21/06, Alec Mitchell [EMAIL PROTECTED] wrote: Indeed it does, the issue is that writing __bobo_traverse__ methods which try to fallback on the normal traversal mechanisms has always been a pain (you have to reimplement the normal traversal mechanisms yourself, including some funny WebDAVisms). If instead the __bobo_traverse__ mechanism could explicitly tell its caller (via an exception) to continue with the standard traversal, it would be a nice improvement. Of course, the real fix may be for products to stop using __bobo_traverse__ and start sing BeforeTraverseEvent subscribers, or IPublshTraverse adapters. This is something I hope to look into in the next couple days. Yeah, that's probably a solution that doesn't require us to increse the complexity of the already overly complex traversal. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote: ... In our local Zope version, I implemented a solution that is (in my opinion) superior: Define an exception UseTraversalDefault that can be used by __bobo_traverse__ to tell the traversal process (either URL traversal in the publisher or restricted/unrestricted/CMF traversal) to use the default lookup. One big advantage is that e.g. Archetypes.BaseObject.BaseObject.__bobo_traverse__ no longer need this horrible dance to decide whether it should or must not create a NullResource. OK, I'm bringing an old thread back to life to propose implementing this change for Zope 2.10. It would be quite nice to get rid of this horrible dance in the next version of Archetypes, and the change would generally allow people to make simpler __bobo_traverse__ methods that don't have to reimplement the traversal machinery themselves, especially since the traversal machinery is a bit in flux these days. Of course, if the plan is to make __bobo_traverse__ obsolete in the near future (provided reasonable alternatives exist), then making it nicer shouldn't really be too much of a priority. Thoughts? Alec ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
--On 20. April 2006 20:29:30 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Up to you to decide whether we may break the general rule (no new features in micro releases) for features of this kind. We've always included minor features that aren't obviously critical micro release. The general rule basically applies applies to really new features. If this patch is acceptable and useful for everyone affected (Alec?). Since I am not directly (or no more) affected by this issue others should vote for or against this change. So we're more pragmatic than pedantic. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgpHOwytdeMXN.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
It would be very nice if we could get a list of use cases and expected behaviour, as I hope to refactor the Zope2 traversal in the near future and get rid of five:traversable completely. To do this without making everybody angry, I need usescases so I can make sure it works. :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
Andreas Jung wrote: --On 20. April 2006 20:29:30 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Up to you to decide whether we may break the general rule (no new features in micro releases) for features of this kind. We've always included minor features that aren't obviously critical micro release. The general rule basically applies applies to really new features. If this patch is acceptable and useful for everyone affected (Alec?). I don't have time to comment on the specific issue. In general, I think that new features in bug-fix releases are a bad idea. Of course, the line between bug-fix and feature is not always crisp. Something that is really a new feature should wait for a feature release. Note that the next feature release should happen in a couple of months. 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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
--On 21. April 2006 07:09:45 -0400 Jim Fulton [EMAIL PROTECTED] wrote: In general, I think that new features in bug-fix releases are a bad idea. Of course, the line between bug-fix and feature is not always crisp. Something that is really a new feature should wait for a feature release. Sure, in this particular case the issue is bug for Alec and Philipp, others consider it a feature :-) A behavior introduced because by some implementation bug is likely to be considered as a bug (this justifies the change in Five 1.3.3) Andreas pgpTlCCX6KjWm.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
On 4/21/06, Andreas Jung [EMAIL PROTECTED] wrote: --On 21. April 2006 07:09:45 -0400 Jim Fulton [EMAIL PROTECTED] wrote: In general, I think that new features in bug-fix releases are a bad idea. Of course, the line between bug-fix and feature is not always crisp. Something that is really a new feature should wait for a feature release. Sure, in this particular case the issue is bug for Alec and Philipp, others consider it a feature :-) A behavior introduced because by some implementation bug is likely to be considered as a bug (this justifies the change in Five 1.3.3) Perhaps it's just my perspective here, but I think it's a stretch to describe the fix I've committed as a feature. Before the fix, when a __bobo_traverse__ method returned an object obtained via acquisition it was treated very differently than an object returned by normal traversal, and when that object had an acquisition wrapper everything works (there is very explicit code and tests that ensure this), however if the object returned has no Acquisition wrapper (because it is a method, string, etc) then a very cryptic Unauthorized error is raised (Container None has no security assertions). It's hard for me to see this as anything but a bug, and the fact that it causes serious problems for anyone who wants to use attribute acquisition with Five makes it a rather serious one. Dieter's proposed fix introduces feature (which I think is the source of this bug/feature confusion). Though as he says, it is one which has close to no consequences because it has no effect until product developers (Five included) take advantage of it by raising a new exception from their __bobo_traverse__ methods. Even in that case, the implementation of the feature should be somewhat tirvial and unlikely to be error prone. Nonetheless, the two proposals serve somewhat different purpooses, though Dieter's new feature could easily be used to allow products to circumvent the above bug and simplify existing product code. Alec ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
Andreas Jung wrote at 2006-4-19 20:13 +0200: --On 19. April 2006 18:38:05 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: ... Do you accept it? ;-) As release manager I don't have to dig into every problem. Patches + tests are of course accepted if there is some consensus that a proposed solution solves the open problem. But I don't have to care about the progress of every ongoing issue. In this case, you may want to say something: I proposed the introduction of a new feature (__bobo_traverse__ can tell the containing framework that it should use the default by raising a special exception). Someone feared that it cannot be added to a micro release as it is a new feature (and not only a bug fix). I argued that this new feature could be acceptable nevertheless, as it affects only components that know about it and use it. Otherwise, it is completely inoffensive. Up to you to decide whether we may break the general rule (no new features in micro releases) for features of this kind. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
Andreas Jung wrote at 2006-4-18 20:54 +0200: ... --On 18. April 2006 18:52:10 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Alec Mitchell wrote at 2006-4-17 14:53 -0700: ... Yes, it does sound like a better solution. However, the issue I see with it is that it is essentially adding new functionality, rather than fixing a problem with the existing behavior. That would seem to make it a much less likely candidate for getting into zope 2.8.7 (which is important IMHO), despite the fact that it is a bit more elegant It is a new functionality -- but one that does nothing until it is used and only for those applications (like five:traversal) that use it. Thus, even a strict release manager might accept it. Am I strict? :-) Do you accept it? ;-) -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
--On 19. April 2006 18:38:05 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Thus, even a strict release manager might accept it. Am I strict? :-) Do you accept it? ;-) As release manager I don't have to dig into every problem. Patches + tests are of course accepted if there is some consensus that a proposed solution solves the open problem. But I don't have to care about the progress of every ongoing issue. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: [EMAIL PROTECTED] - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope Plone development, Consulting pgp9Fio97lEGO.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
Alec Mitchell wrote at 2006-4-17 14:53 -0700: ... Yes, it does sound like a better solution. However, the issue I see with it is that it is essentially adding new functionality, rather than fixing a problem with the existing behavior. That would seem to make it a much less likely candidate for getting into zope 2.8.7 (which is important IMHO), despite the fact that it is a bit more elegant It is a new functionality -- but one that does nothing until it is used and only for those applications (like five:traversal) that use it. Thus, even a strict release manager might accept it. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
--On 18. April 2006 18:52:10 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Alec Mitchell wrote at 2006-4-17 14:53 -0700: ... Yes, it does sound like a better solution. However, the issue I see with it is that it is essentially adding new functionality, rather than fixing a problem with the existing behavior. That would seem to make it a much less likely candidate for getting into zope 2.8.7 (which is important IMHO), despite the fact that it is a bit more elegant It is a new functionality -- but one that does nothing until it is used and only for those applications (like five:traversal) that use it. Thus, even a strict release manager might accept it. Am I strict? :-) Andreas pgpUImvsRhSjW.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
Alec Mitchell wrote at 2006-4-16 12:28 -0700: ... It seems that the way OFS.Traversable.restrictedTraverse() handles security checking on objects with __bobo_traverse__ methods is considerably different from the way it normally checks security. The result is that traversal cannot obtain attributes using acquisition from objects that are marked five:traversable. In the normal case, security is checked using guarded_getattr, which gets an attribute and checks the permissions on the retrieved object in its original context. For __bobo_traverse__methods which return simple properties (say strings), it is impossible to determine the container from which the returned attribute originates, so unless the attribute was not acquired, an Unauthorized error will always be raised. ... However, IMHO fixing this makes sense for Zope itself, provided there aren't any undesirable consequences. I propose that if the validation of a __bobo_traverse result raises Unauthorized, that we make one last check to see if the result o 'guarded_getattr(obj, name)' is identical to the result of the __bobo_traverse__ call and allow it if that's the case. Here is my proposed patch against Zope 2.9 trunk: In our local Zope version, I implemented a solution that is (in my opinion) superior: Define an exception UseTraversalDefault that can be used by __bobo_traverse__ to tell the traversal process (either URL traversal in the publisher or restricted/unrestricted/CMF traversal) to use the default lookup. One big advantage is that e.g. Archetypes.BaseObject.BaseObject.__bobo_traverse__ no longer need this horrible dance to decide whether it should or must not create a NullResource. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Traversal issue which affects Five
On 4/17/06, Dieter Maurer [EMAIL PROTECTED] wrote: Alec Mitchell wrote at 2006-4-16 12:28 -0700: ... It seems that the way OFS.Traversable.restrictedTraverse() handles security checking on objects with __bobo_traverse__ methods is considerably different from the way it normally checks security. The result is that traversal cannot obtain attributes using acquisition from objects that are marked five:traversable. In the normal case, security is checked using guarded_getattr, which gets an attribute and checks the permissions on the retrieved object in its original context. For __bobo_traverse__methods which return simple properties (say strings), it is impossible to determine the container from which the returned attribute originates, so unless the attribute was not acquired, an Unauthorized error will always be raised. ... However, IMHO fixing this makes sense for Zope itself, provided there aren't any undesirable consequences. I propose that if the validation of a __bobo_traverse result raises Unauthorized, that we make one last check to see if the result o 'guarded_getattr(obj, name)' is identical to the result of the __bobo_traverse__ call and allow it if that's the case. Here is my proposed patch against Zope 2.9 trunk: In our local Zope version, I implemented a solution that is (in my opinion) superior: Define an exception UseTraversalDefault that can be used by __bobo_traverse__ to tell the traversal process (either URL traversal in the publisher or restricted/unrestricted/CMF traversal) to use the default lookup. One big advantage is that e.g. Archetypes.BaseObject.BaseObject.__bobo_traverse__ no longer need this horrible dance to decide whether it should or must not create a NullResource. Yes, it does sound like a better solution. However, the issue I see with it is that it is essentially adding new functionality, rather than fixing a problem with the existing behavior. That would seem to make it a much less likely candidate for getting into zope 2.8.7 (which is important IMHO), despite the fact that it is a bit more elegant. In fact, I would say that even with this clever exception handling, there may still be cases where one wants to return an acquired attribute directly from a __bobo_traverse__, without simply falling back on the default behavior (say if one wants to limit the acquirable names or some other silly thing). So the two solutions can coexist peacefully; though the exception based solution is likely to allow a lot of nice simplifications to some of the hacky __bobo_traverses__ out there. Alec ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
