May 2006 - Zope-Dev - Zope lists

Traversal issue which affects Five
by Alec Mitchell 21 Aug '06

21 Aug '06

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 <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. 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

6 16

zope2 requests VS zope3 requests
by Rocky Burt 07 Jun '06

07 Jun '06

Hi all, After trying to get zope3-style locale information from a zope2 request for another task today I discovered I had no idea what the plan was regarding uniting these two request models in short-term or long-term (or even if there are any plans). I've heard rumours that ultimately the preferred manner of integration of z2 and z3 requests was to replace the z2 ZPublisher with the z3 zope.publisher. Perhaps those are just rumours, I have no idea. In any event, that would certainly be long-term. But are we doing anything in the short-term? My naive idea was that perhaps we should start building FrankenHTTPRequest which extended the original ZPublisher HTTPRequest but then also implemented zope.publisher's IHTTPRequest interface. This would give us a fairly safe combination of both requests and enable more zope3 applications to work as-is on Zope 2 (the one example that comes to mind is zope3's formlib which requires locale information to be present on the active request based on zope.publisher's IHTTPRequest). To be honest I'm only throwing random ideas out here just to spark a discussion. Maybe you all have already figured out the appropriate game plan. Either way, I'd just like to know :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net

5 6

Zope 2.10 deprecation warnings
by Florent Guillaume 01 Jun '06

01 Jun '06

Current bare Zope 2.10 sends some deprecation warnings because it itself imports things that it deprecates, this will have to be hidden. Suggestions welcome: - App/Product.py imports ZClasses which are deprecated, - Products/ZCatalog/ZCatalog.py imports TextIndex (for the Splitters) but TextIndex is deprecated. Also I've checked in a fix for the ZPT warnings such as: Init Ambiguous name for method of Products.PageTemplates.ZopePageTemplate.ZopePageTemplate: 'manage' != 'manage_main' Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg(a)nuxeo.com

2 2

tempstorage to ZEO?
by Sidnei da Silva 01 Jun '06

01 Jun '06

I was looking, and trying to understand why 'tempstorage' is not included in the ZODB. Since some people might want to share sessions between ZEO clients, and that 'tempstorage' is what is mounted as '/temp_folder/session_data', why not make that easy to mount via ZEO? Does anyone see a problem with this? What I'm proposing is to move 'tempstorage' to 'ZODB', since it has no dependency on anything other than 'zLOG'. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214

6 16

Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testZopePageTemplate.py A recent fix in the zope 3 traversing code now requires the ITraversable
by Tres Seaver 31 May '06

31 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Log message for revision 68328: > A recent fix in the zope 3 traversing code now requires the ITraversable > adapter to be present even when traversing just dicts. No problem, we can > set it up quite easily. > > This basically finishes this branch. All tests pass, some 3rd party apps > have been tested with it. There are a few test failures in the CMF and > others (e.g. Plone), but that's mostly "their fault" (incorrect or > unexpected usage of certain things). Those are BBB fouls, as those failures do not emit deprecation warnings when run against 2.9. In fact, none of the deprecation warnings which are raised when running the CMF 2.0 tests under 2.9 allow for failures under 2.10. The failrures are mostly instances of: - The "empty path element" exception. Zope3's choice to make that an error is undefended, AFAIK (Fred never replied to your query about the reason), and needs BBB in any case. - CMFDefault/skin/configure.zcml blows up because the syntax of the 'browser:skin' directive has changed in a BBB-incompatible way. The now-failing directive is:: <browser:skin name="cmf" layers="cmf default" /> and the traceback is *very* weird:: ZopeXMLConfigurationError: File \ "/tmp/endgame/Products/CMFDefault/skin/configure.zcml", line \ 10.2-13.8 ConfigurationError: ('Invalid value for', 'layers', "ImportError:\ Couldn't import default, No module named default in cmf default") - "No traversable adapter found" raised out of 'boboAwareZopeTraverse'. This one is likely due to the prior ZCML issue, which blows out ZCML processing early. These problems aren't blockers for a 2.10 beta, but they must be resolved before a final release. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEelcj+gerLs4ltQ4RAqRcAJ0feXoFF2V19kS0VBRuwmW4BDkGFQCeM8Ta VRMWb2tyUuWSSzL1EtM80bk= =7/6v -----END PGP SIGNATURE-----

7 15

Re: SVN: Products.Five/trunk/ Five now requires site.zcml to live in /etc
by Tres Seaver 30 May '06

30 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rocky Burt wrote: > Log message for revision 68359: > Five now requires site.zcml to live in /etc > > Changed: > U Products.Five/trunk/CHANGES.txt > D Products.Five/trunk/skel/ > U Products.Five/trunk/zcml.py > > -=- > Modified: Products.Five/trunk/CHANGES.txt > =================================================================== > --- Products.Five/trunk/CHANGES.txt 2006-05-29 19:42:51 UTC (rev 68358) > +++ Products.Five/trunk/CHANGES.txt 2006-05-29 20:24:13 UTC (rev 68359) > @@ -8,6 +8,18 @@ > Restructuring > ------------- > > +* Zope 2.10+ now includes site.zcml as part of its instance creation > + skel directory. As a consequence Five now requires this file to exist > + in every instance. If upgrading a site from Zope 2.9 to 2.10, you will > + need to copy site.zcml and package-includes/ from your installed Zope > + installation location (skel/etc/) into the etc/ directory of your upgraded > + instance. > + > + The rationale for requiring this new file is to bring Zope 2 instances > + closer in consistency to Zope 3 instances. It also eases use of Zope 3 > + coding techniques in Zope 2 and removes some confusion when trying > + to run pure Zope 3 applications on Zope 2. This is a BBB foul. The appropriate way to make such a change is to add a deprecation warning, leaveing the "old" behavior (which was to use the 'site.zcml' from inside Five) in place. Making "forward compatibility" smoother is *less* important than preserving "backward compatibility". Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfHlq+gerLs4ltQ4RAlNbAJ9IISl/plYHaMXb7DuEEEvVMJu9pwCeMASk R/kuYOm5U9F03unBpcApm58= =hehK -----END PGP SIGNATURE-----

3 2

2.10 branch and trunk
by Andreas Jung 30 May '06

30 May '06

Hi, I plan to create a branch for Zope 2.10 after 2.10beta 2 or short before the 2.10 final release. This means that the Zope trunk should only be used for bugfixes *only* until the branch is cut. So no new development and feature should happen on the trunk until then..Use your own branch until the trunk is open for new stuff to appear in Zope 2.11. Thanks, Andreas

4 9

Re: SVN: Zope/trunk/doc/CHANGES.txt remove 2.8 related entries
by Tres Seaver 30 May '06

30 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Death to HISTORY.txt. I don't see purpose of this file. All historic > informations are available as CHANGES.txt on the different branches. - -1. It gives the person looking at the tarball a way to check for past bugfixes, etc. Some of those folks *aren't* core developers (e.g., they might be packaging Zope for a Linux distro), and shouldn't be required to use developers' tools to find that information. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfIHS+gerLs4ltQ4RAgnLAJ9t7DD53XKEj1a+sE9kk0RjkltzCACfbF/3 mMUUd9rgAkIQX4/B9uLVbB8= =gyMw -----END PGP SIGNATURE-----

1 0

Re: SVN: Zope/trunk/doc/CHANGES.txt remove 2.8 related entries
by Tres Seaver 30 May '06

30 May '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote: > Log message for revision 68387: > remove 2.8 related entries Those entries need to be added to doc/HISTORY.txt, don't they? Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEfHgH+gerLs4ltQ4RAk4jAJwLfK0IOySIYOKxKGeSsFUihRaK/gCfewQj Yh6EODtpdEMBxMZJP6x7aRE= =S/1k -----END PGP SIGNATURE-----

1 0

Five release fest: Five 1.2.5, 1.3.6, 1.4 and 1.5c released!
by Philipp von Weitershausen 29 May '06

29 May '06

The Five team is happy to announce the release of two Five bugfix releases, 1.2.5 and 1.3.6, a Five 1.4 final release and another Five 1.5c beta release today. What is Five ------------ Five is a Zope 2 product that allows you to integrate Zope 3 technologies into Zope 2, today. Among others, it allows you to use Zope 3 interfaces, ZCML-based configuration, adapters, browser pages (including skins, layers, and resources), automated add and edit forms based on schemas, object events, as well as Zope 3-style i18n message catalogs. We've tried to keep the Five experience as close to Zope 3 as possible, so this means that what you learn while using Five should also be applicable to Zope 3, and viceversa. More information about Five can be found on our website, http://codespeak.net/z3/five/. About Five 1.4 and 1.5 ---------------------- Five 1.4 and 1.5 are feature releases. They are basically equivalent except that Five 1.4 works with Zope 2.9/3.2 (only) and 1.5 works with Zope 2.10/3.3 (only). Five 1.5 will be included in Zope 2.10. Most important features are: * Added viewlet and content provider support. A big thanks to Alec Mitchell and his helpers at the Archipelago sprint for making this possible. * Add zope.formlib support. Please see ``doc/formlib.txt`` for more information. A big thanks to Jan-Wijbrand Kolman for this. * Port zope.testbrowser to Zope 2. You can now use Products.Five.testbrowser.Browser in functional tests. Much thanks to Brian Sutherland. * Add python-packages-as-zope-products support which basically allows for using any python package as a zope product without it having to live in Products/. Much thanks to Rocky Burt for this. Zope 2.10 and Five 1.5 are also a big milestone in the convergence of Zope 2 and Zope 3, for it is no longer necessary to mark classes with five:traversable and five:defaultViewable to enable Zope 3 view lookup functionality. A big thanks goes to Lennart Regebro and Michael Kerrin for making this possible! Changes in Five 1.2.5, 1.3.6, 1.4 (vs. 1.4c), 1.5c (vs. 1.5b) ------------------------------------------------------------- * Fixed an issue where <browser:page> based views that didn't have template or attribute defined weren't getting BrowserView mixed in. * Fixed an issue where new-style classes could not be used for view components with <browser:page>. * Five.testbrowser does not swallow cookies anymore, based on patch by Daniel Nouri. * Five.testbrowser capitalizes headers in the same way as the Zope2 HTTPResponse. i.e. content-length -> Content-Length. About the Zope 3 Base --------------------- Five is part of the *Zope 3 Base* project, which aims to offer an approachable area for developers of Zope 3 related software. More about the Zope 3 base and its projects can be found on the project website, http://codespeak.net/z3/.

1 0