Re: [Zope-dev] MailHost Improvements
On Thu, 13 Aug 2009 21:22:07 -0700, Alec Mitchell wrote: > On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jung wrote: >> On 13.08.09 01:03, Alec Mitchell wrote: >>> Hello, >>> >>> I've been working on making Plone use the standard Zope MailHost in >>> place of the custom Products.SecureMailHost we've been using since >>> Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this >>> process I've run into a couple bugs in the MailHost implementation and >>> I believe it is missing some essential functionality. >>> >>> The most significant issue is that if you call send() with a >>> messageText containing just the message body, and that body has a ':' >>> in it (e.g. a url) the body will be treated as a header and you'll >>> send a nonsense message. The current implementation of send() also >>> puts a fairly large burden on developers who want to generate simple, >>> correctly encoded messages. Finally, send() relies heavily on the >>> long deprecated 'rfc822' and 'mimetools' modules which have been >>> removed from Python 3.0. >>> >>> I've attached a patch that updates MailHost to use the 'email' module >>> for parsing and generating messages. In addition to fixing the issues >>> that I ran across, and maintaining compatibility, it provides a number >>> of new features: >>> >>> * send and sendTemplate accept an optional charset argument. Using >>> this will set the content-type charset, as well as trigger appropriate >>> encoding if needed. >>> >>> * send and sendTemplate accept an optional msg_type argument which >>> will set the content type header for the message. >>> >>> * The messageText, mfrom, mto, and subject arguments may now be >>> unicode or encoded non-ascii strings, provided a charset is given. >>> Any unicode input will be automatically encoded to the provided >>> charset (or the default charset). Headers will be further encoded in >>> compliance with rfc2822. The message body will be further encoded >>> using a transfer encoding determined by the email.Charset registry >>> (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, >>> base64 for most other encodings). >>> >>> * The messageText argument now accepts email.Message.Message objects >>> directly. >>> >>> I'm attaching a patch that includes these changes as well as tests for >>> all new functionality. I hope to integrate these changes into Zope >>> 2.12 before final release, but would like to hear the opinions of Zope >>> developers before committing. Though these are fairly significant >>> changes, I believe they provide very useful functionality as well as >>> at least one critical fix, while maintaining 100% compatibility. >> >> This comes very, very late. We are pretty close to a release. Please put >> the changes on the trunk only. >> We will check after my vacation if we can move it into the 2.12 beta. > > I've put my latest changes on Zope trunk. All the existing tests pass > (with a couple essentially cosmetic modifications in the MailHost > tests), and there are 14 new tests which verify both existing and new > functionality, as well as the fixed bugs. The new behavior should be > identical to the existing behavior when the new charset and msg_type > parameters aren't used, with the following exceptions: > > 1) Passing a message body containing a ':' no longer produces a nonsense > email. > 2) Providing unicode strings for the text or headers no longer results > in a garbage message (it may produce a UnicodeEncodeError though). > 3) 8bit (encoded) strings provided as headers will be converted to > 7bit, using encoding determined in messageText headers or the default > encoding. > > It would be very helpful to have these changes in Zope 2.12; > otherwise, Plone 4.0 will be stuck with our unmaintained > SecureMailHost product for yet another release in order to provide > equivalent functionality. Moving to a standard Zope MailHost would be > a big benefit for Plone, and all Zope users will benefit from the > ability to easily send properly formed non-ASCII messages. There's one additional significant change to Zope behavior here that I forgot to mention. The current implementation sets the python default email transfer and header encoding for 'utf-8' messages to 'quoted-printable', it normally defaults to 'base64'. This is essentially a cosmetic
Re: [Zope-dev] MailHost Improvements
On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jung wrote: > On 13.08.09 01:03, Alec Mitchell wrote: >> Hello, >> >> I've been working on making Plone use the standard Zope MailHost in >> place of the custom Products.SecureMailHost we've been using since >> Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this >> process I've run into a couple bugs in the MailHost implementation and >> I believe it is missing some essential functionality. >> >> The most significant issue is that if you call send() with a >> messageText containing just the message body, and that body has a ':' >> in it (e.g. a url) the body will be treated as a header and you'll >> send a nonsense message. The current implementation of send() also >> puts a fairly large burden on developers who want to generate simple, >> correctly encoded messages. Finally, send() relies heavily on the >> long deprecated 'rfc822' and 'mimetools' modules which have been >> removed from Python 3.0. >> >> I've attached a patch that updates MailHost to use the 'email' module >> for parsing and generating messages. In addition to fixing the issues >> that I ran across, and maintaining compatibility, it provides a number >> of new features: >> >> * send and sendTemplate accept an optional charset argument. Using >> this will set the content-type charset, as well as trigger appropriate >> encoding if needed. >> >> * send and sendTemplate accept an optional msg_type argument which >> will set the content type header for the message. >> >> * The messageText, mfrom, mto, and subject arguments may now be >> unicode or encoded non-ascii strings, provided a charset is given. >> Any unicode input will be automatically encoded to the provided >> charset (or the default charset). Headers will be further encoded in >> compliance with rfc2822. The message body will be further encoded >> using a transfer encoding determined by the email.Charset registry >> (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, >> base64 for most other encodings). >> >> * The messageText argument now accepts email.Message.Message objects >> directly. >> >> I'm attaching a patch that includes these changes as well as tests for >> all new functionality. I hope to integrate these changes into Zope >> 2.12 before final release, but would like to hear the opinions of Zope >> developers before committing. Though these are fairly significant >> changes, I believe they provide very useful functionality as well as >> at least one critical fix, while maintaining 100% compatibility. > > This comes very, very late. We are pretty close to a release. Please put > the changes on the trunk only. > We will check after my vacation if we can move it into the 2.12 beta. I've put my latest changes on Zope trunk. All the existing tests pass (with a couple essentially cosmetic modifications in the MailHost tests), and there are 14 new tests which verify both existing and new functionality, as well as the fixed bugs. The new behavior should be identical to the existing behavior when the new charset and msg_type parameters aren't used, with the following exceptions: 1) Passing a message body containing a ':' no longer produces a nonsense email. 2) Providing unicode strings for the text or headers no longer results in a garbage message (it may produce a UnicodeEncodeError though). 3) 8bit (encoded) strings provided as headers will be converted to 7bit, using encoding determined in messageText headers or the default encoding. It would be very helpful to have these changes in Zope 2.12; otherwise, Plone 4.0 will be stuck with our unmaintained SecureMailHost product for yet another release in order to provide equivalent functionality. Moving to a standard Zope MailHost would be a big benefit for Plone, and all Zope users will benefit from the ability to easily send properly formed non-ASCII messages. Alec P.S. Andreas, if there's an address where I can send some nice wine to help facilitate the merge into 2.12, let me know ;-) ___ 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 )
[Zope-dev] MailHost Improvements
Hello, I've been working on making Plone use the standard Zope MailHost in place of the custom Products.SecureMailHost we've been using since Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this process I've run into a couple bugs in the MailHost implementation and I believe it is missing some essential functionality. The most significant issue is that if you call send() with a messageText containing just the message body, and that body has a ':' in it (e.g. a url) the body will be treated as a header and you'll send a nonsense message. The current implementation of send() also puts a fairly large burden on developers who want to generate simple, correctly encoded messages. Finally, send() relies heavily on the long deprecated 'rfc822' and 'mimetools' modules which have been removed from Python 3.0. I've attached a patch that updates MailHost to use the 'email' module for parsing and generating messages. In addition to fixing the issues that I ran across, and maintaining compatibility, it provides a number of new features: * send and sendTemplate accept an optional charset argument. Using this will set the content-type charset, as well as trigger appropriate encoding if needed. * send and sendTemplate accept an optional msg_type argument which will set the content type header for the message. * The messageText, mfrom, mto, and subject arguments may now be unicode or encoded non-ascii strings, provided a charset is given. Any unicode input will be automatically encoded to the provided charset (or the default charset). Headers will be further encoded in compliance with rfc2822. The message body will be further encoded using a transfer encoding determined by the email.Charset registry (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, base64 for most other encodings). * The messageText argument now accepts email.Message.Message objects directly. I'm attaching a patch that includes these changes as well as tests for all new functionality. I hope to integrate these changes into Zope 2.12 before final release, but would like to hear the opinions of Zope developers before committing. Though these are fairly significant changes, I believe they provide very useful functionality as well as at least one critical fix, while maintaining 100% compatibility. Thanks, Alec mailhost.patch Description: Binary data ___ 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] adapting to None
Chris Withers simplistix.co.uk> writes: > > Hi All, > > I have a need to be able to adapting certain objects to None, eg: > > def some_adapter(obj): >if something: > return None >return somethingelse > > This is tricky, since returning None from an adapter results in a TypeError. > > I eventually came up with the idea of having a subclass of Interface do > what I needed: > > empty = object() > > class IFieldType(Interface): > def __call__(self,*args,**kw): > r = Interface.__call__(*args,**kw) > if r is empty: > return None > return r > > I suspect this would work with the python implementation of Interface, > but it certainly doesn't with the C implementation. > > What am I doing wrong and how can I achieve what I'm after? If the result of an adaptation is None, it means something very specific to the CA. That TypeError is specifically a 'Could not adapt' TypeError, which is similar to a ComponentLookupError but with a slightly different meaning (not sure why the CA doesn't use a custom exception for this). This feature allows you to create an adapter which is capable of inspecting its arguments and determining that it's not capable of adapting those particular objects. Because an adapter that returns None has this specific meaning, you can't actually adapt something to None. You'll have to use queryAdapter or explicitly handle the exception. 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] TypesTool speedup
Looking at the changes rocky made, I don't see why allowing external methods from non-Products should require making the whole process completely dynamic on every call. The old mechanism of storing the product list should be put back in place, along with the addition of non-Product information to these results. 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, 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 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: The hotfix that isn't? (was: Re: [Zope-dev] 2.9.4? reStructuredText support?)
On 7/8/06, Sidnei da Silva <[EMAIL PROTECTED]> wrote: Just to make the matters clear, when you say 'the last hotfix' Jim, do you mean the Hotfix-20060705? I ask because I'm about to roll a hotfix installer for Plone and if there's an issue with that one I can hold back the installer. It looks to me like the only issue with it is the lack of tests. The inadequate hotfix appears to be one from last fall which attempted to address the same issue. 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] Zope 2.9.3 release
On 5/9/06, Andreas Jung <[EMAIL PROTECTED]> wrote: --On 9. Mai 2006 17:32:06 -0700 Alec Mitchell <[EMAIL PROTECTED]> wrote: > On 5/9/06, Andreas Jung <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I plan to release Zope 2.9.3 by this weekend. The release contains >> some important fixes and a Five update. Any objections? > > Sounds good to me, any chance of a new 2.8 release as well? Or is 2.8 > completey 100% dead already. I'll have to look at the changelog first... My main concern is that the traversal security issue which affects any object that tries to acquire attributes and has been marked five:traversable (thankfully this nonsense is gone in 2.10) was a problem for both 2.8 and 2.9. Unless there's a 2.8 with that fix, Plone 2.5 will not be able to run on Zope 2.8. Though this would doubtlessly make a few people happy, the Plone Windows installer apparently needs to use 2.8 unless the Plone release is heavily delayed to get the installer woking with Python 2.4/Zope 2.9. 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] Zope 2.9.3 release
On 5/9/06, Andreas Jung <[EMAIL PROTECTED]> wrote: Hi, I plan to release Zope 2.9.3 by this weekend. The release contains some important fixes and a Five update. Any objections? Sounds good to me, any chance of a new 2.8 release as well? Or is 2.8 completey 100% dead already. 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 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] Re: Zope 2.9.3 release
On 4/20/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: > Tres Seaver wrote at 2006-4-19 15:30 -0400: > > ... > >> Is Alec's traversal patch or Dieter's alternative being considered? > > > >I'll note that I have a client who can't move forward from 2.9.1 to > >2.9.3 because the changes to traversal semantics in that release break > >every view lookup in the application (which was originally built on > >2.8.x, and works fine on 2.9.1. > > I would like to stress that "my alternative" does not change traversal > semantics but provides a way for "knowing" component's > "__bobo_traverse__" to tell the enclosing framework that > "__bobo_traverse__" wants to use the default (and not do anything special). > Nothing is changed until a given component uses the feature. And I'll stress that my change doesn't change traversal behavior either for any case that didn't emit and Unauthorized error previously. It is also completely compatible with Dieter's proposal, which is worthwhile because it could allow many existing __bobo_traverse__ methods to be greatly simplified. I've applied my patch to 2.8, 2.9, and trunk because a Zope release appears to be imminent, and there's no way we can release a new Plone until we have a Zope/Five which can handle acquisition properly (I'm pretty sure that this will bite other projects as well). 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 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 . 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 )
[Zope-dev] Re: Traversal issue which affects Five
On 4/17/06, Florent Guillaume <[EMAIL PROTECTED]> wrote: > Hi Alec, > > Five traversal is definitely very touchy, and the interactions with Zope > numerous. So I'm sure the problem you observed is real and that a > solution must be found. The unit tests you propose would go a long way > to having a fix committed asap, so yes please, provide one. ... > Alec Mitchell wrote: > > 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 . 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. > > > > Objects that are Five Traversable always have __bobo_traverse__ > > methods which attempt to mimic normal traversal, which effectively > > means that the security checks end up preventing acquisition of simple > > properties using traversal from ever working on these objects (say > > using a TAL path expression 'context/attribute' which you expect to be > > acquired). Unfortunately, because Five has no control over the > > security checks done during traversal, this cannot be fixed directly > > in Five. 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: > > At the moment Plone 2.5 is really struggling with this issue, and it > > would be wonderful if a fix for this could go into Zope 2.8 and 2.9 > > soon. I'm happy to write tests for this, I just want to make sure > > that I'm not proposing something really wrong/inappropriate here. > > Generally, the validate() call should return a True or False value, so > > this change should have little performance impact except in the case > > where 'container == _none' and validate would otherwise raise a very > > unhelpful unauthorized error. Your feedback is much appreciated. Ok, I've attached a refined patch with tests. Only one of these will fail with the original version of Traversable.py (testBoboTraverseToAcquiredAttribute), the other three just make sure that expected security restrictions and behavior are preserved. I'll reiterate that fixing this issue is quite essential for Plone, and likely for any other reasonably complex Zope 2 project which wishes to use Five/Zope3 extensively. I'll file a collector issue later today. Alec bobo_traverse_security.diff Description: Binary data ___ 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 )
[Zope-dev] Traversal issue which affects Five
Hi all, 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 . 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. Objects that are Five Traversable always have __bobo_traverse__ methods which attempt to mimic normal traversal, which effectively means that the security checks end up preventing acquisition of simple properties using traversal from ever working on these objects (say using a TAL path expression 'context/attribute' which you expect to be acquired). Unfortunately, because Five has no control over the security checks done during traversal, this cannot be fixed directly in Five. 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: --- Traversable.py (revision 66323) +++ Traversable.py (working copy) @@ -201,9 +201,18 @@ else: # Can't determine container container = _none -if not securityManager.validate( -obj, container, name, next): -raise Unauthorized, name +try: +if not securityManager.validate( +obj, container, name, next): +raise Unauthorized, name +except Unauthorized: +# If next is a simple unwrapped property, it's +# parentage is indeterminate, but it may have been +# acquired safely. In this case validate will raise +# an error, and we can check that our value was +# acquired safely. +if guarded_getattr(obj, name, marker) is not next: +raise Unauthorized, name else: if restricted: next = guarded_getattr(obj, name, marker) At the moment Plone 2.5 is really struggling with this issue, and it would be wonderful if a fix for this could go into Zope 2.8 and 2.9 soon. I'm happy to write tests for this, I just want to make sure that I'm not proposing something really wrong/inappropriate here. Generally, the validate() call should return a True or False value, so this change should have little performance impact except in the case where 'container == _none' and validate would otherwise raise a very unhelpful unauthorized error. Your feedback is much appreciated. Alec Mitchell ___ 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 )
[Zope-dev] Re: [Zope2.8.7] with Five 1.0 or Five 1.2
Andreas Jung zopyx.com> writes: ... > Should we upgrade the Five version in Zope 2.8 to Five > 1.2 to make their lives a bit easier? +1 on a 2.8.7 with a viable Five. Alec Mitchell ___ 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 )
