- Zope-Dev - Zope lists

Re: [Zope-dev] SVN: Zope/branches/2.12/ Correctly handle unauthorized exceptions in the ZPublisherExceptionHook.
by Tres Seaver 10 Jul '09

10 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote: > Log message for revision 101181: > Correctly handle unauthorized exceptions in the ZPublisherExceptionHook. > > Modified: Zope/branches/2.12/src/Zope2/App/startup.py > =================================================================== > --- Zope/branches/2.12/src/Zope2/App/startup.py 2009-06-20 19:53:08 UTC (rev 101180) > +++ Zope/branches/2.12/src/Zope2/App/startup.py 2009-06-21 00:00:53 UTC (rev 101181) > @@ -24,6 +24,7 @@ > from time import asctime > from types import StringType, ListType > from zExceptions import Redirect > +from zExceptions import Unauthorized > from ZODB.POSException import ConflictError > import transaction > import AccessControl.User > @@ -170,7 +171,7 @@ > if t.lower() in ('unauthorized', 'redirect'): > raise > else: > - if t is SystemExit or t is Redirect: > + if t is SystemExit or t is Redirect or t is Unauthorized: > raise > > if issubclass(t, ConflictError): What is the motivation here? Zope2 applications have hooked Unauthorized exceptions *forever*: - You can see them in the error_log (if you take them out of the ignore list). This change (the fixed version) breaks unit tests which assert that the exception can be hooked: - -------------------------------------------------------------------------- $ bin/test -s Zope2.App Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Error in test testRenderUnauthorizedBrokenClient (Zope2.App.tests.testExceptionHook.ExceptionMessageRenderTest) Traceback (most recent call last): File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 279, in run testMethod() File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 284, in testRenderUnauthorizedBrokenClient self.assertRaises(AttributeError, self.call, client, request, f) File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 336, in failUnlessRaises callableObj(*args, **kwargs) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 74, in call sys.exc_info()[2], File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 69, in call f(*args, **kw) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 281, in f raise Unauthorized, 1 Unauthorized: You are not allowed to access '1' in this context Error in test testRenderUnauthorizedOldClient (Zope2.App.tests.testExceptionHook.ExceptionMessageRenderTest) Traceback (most recent call last): File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 279, in run testMethod() File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 251, in testRenderUnauthorizedOldClient self.call(client, request, f) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 74, in call sys.exc_info()[2], File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 69, in call f(*args, **kw) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 248, in f raise Unauthorized, 1 Unauthorized: You are not allowed to access '1' in this context Error in test testRenderUnauthorizedStandardClient (Zope2.App.tests.testExceptionHook.ExceptionMessageRenderTest) Traceback (most recent call last): File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 279, in run testMethod() File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 262, in testRenderUnauthorizedStandardClient self.call(client, request, f) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 74, in call sys.exc_info()[2], File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 69, in call f(*args, **kw) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 259, in f raise Unauthorized, 1 Unauthorized: You are not allowed to access '1' in this context Error in test testRenderUnauthorizedStandardClientMethod (Zope2.App.tests.testExceptionHook.ExceptionMessageRenderTest) Traceback (most recent call last): File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 279, in run testMethod() File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 273, in testRenderUnauthorizedStandardClientMethod self.call(client.dummyMethod, request, f) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 74, in call sys.exc_info()[2], File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 69, in call f(*args, **kw) File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 270, in f raise Unauthorized, 1 Unauthorized: You are not allowed to access '1' in this context Failure in test testCustomExceptionViewUnauthorized (Zope2.App.tests.testExceptionHook.ExceptionViewsTest) Traceback (most recent call last): File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 279, in run testMethod() File "/home/tseaver/projects/Zope-CVS/Zope-trunk/src/Zope2/App/tests/testExceptionHook.py", line 353, in testCustomExceptionViewUnauthorized self.failUnless(isinstance(v, HTTPResponse), v) File "/home/tseaver/projects/Zope-CVS/lib/python2.6/unittest.py", line 325, in failUnless if not expr: raise self.failureException, msg AssertionError: You are not allowed to access '1' in this context Ran 23 tests with 1 failures and 4 errors in 0.512 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. - -------------------------------------------------------------------------- Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKT5lk+gerLs4ltQ4RAuXKAJ4x+m289pMfGeYprwdJgAJ/6RkIBACdG8FO VYiQVeOKXbGSQ/g65GkP0sw= =RH3T -----END PGP SIGNATURE-----

2 1

z3c.form pass context to multi widgets in MultiConverter
by Gerhard Weis 08 Jul '09

08 Jul '09

Hi, some widgets may require a valid context to work properly. one such widget is z3c.formquery. The attached patch passes the current widget's context to the sub widgets during data conversion in z3c.form.converter.MultiConverter. The patch handles this the same way as passing the form property is implemented. (The patch is against current trunk). Sorry, but I was not sure how to add a test for this. (However, there is also no explicit test for passing the form property). I ran the current test suite with python2.4 and it did not cause any additional issues :) . The second patch here was required on my system. It seems, that zope.app.component is a missing dependency for z3c.form. (at least for now). cheers, Gerhard ------------------------------------------------------------------------ Index: src/z3c/form/converter.py =================================================================== --- src/z3c/form/converter.py (revision 101721) +++ src/z3c/form/converter.py (working copy) @@ -359,6 +359,10 @@ #form property required by objecwidget widget.form = self.widget.form zope.interface.alsoProvides(widget, interfaces.IFormAware) + if interfaces.IContextAware.providedBy(self.widget): + # context property may be required by objectwidget + widget.context = self.widget.context + zope.interface.alsoProvides(widget, interface.IContextAware) converter = zope.component.getMultiAdapter((field, widget), interfaces.IDataConverter) @@ -377,6 +381,10 @@ #form property required by objecwidget widget.form = self.widget.form zope.interface.alsoProvides(widget, interfaces.IFormAware) + if interfaces.IContextAware.providedBy(self.widget): + # context property may be required by objectwidget + widget.context = self.widget.context + zope.interface.alsoProvides(widget, interface.IContextAware) converter = zope.component.getMultiAdapter((field, widget), interfaces.IDataConverter) ------------------------------------------------------------------------ Index: setup.py =================================================================== --- setup.py (revision 101721) +++ setup.py (working copy) @@ -84,6 +84,7 @@ 'z3c.coverage', 'z3c.template', 'zc.sourcefactory', + 'zope.app.component', 'zope.app.container', 'zope.app.i18n', 'zope.app.pagetemplate',

2 4

zope.proxy, c-extensions fallback?
by Jens W. Klein 08 Jul '09

08 Jul '09

Hi, I'am just playing with repoze.bfg in google appengine (gae) and stumbled over zope.proxy. I tried to use zodict.node.Node which depends on zope.location. zope.location depends on zope.proxy. Latter has mandatory C-extensions. Are there any plans to get rid of them as a fallback for those spezial cases like gae? For zope.interface it was possible too ... tia -- Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance

2 1

How to test changes to ZTK packages?
by Jim Fulton 07 Jul '09

07 Jul '09

I should know this, but I don't. What is the recommended way to test changes to core ZTK packages to mitigate the risk that changes affect other packages? Is there a page somewhere with instructions? I tried using using zope.release. Building the trunk of zope.release with Python 2.4 and running the tests gives lots of test import errors and test failures. (Lots of tests want to import z3c.pt.) The tests hang when I try to build and run with Python 2.6. BTW, zope.release wants lxml, which is a real pain on Mac OS X and Centos 4. Does the ZTK really need to depend on lxml? Jim -- Jim Fulton Zope Corporation

11 26

Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a co
by Hanno Schlichting 07 Jul '09

07 Jul '09

On Tue, Jul 7, 2009 at 2:31 AM, Tres Seaver<tseaver(a)palladion.com> wrote: > Hanno Schlichting wrote: >> Log message for revision 101616: >> Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production. > > Shouldn't we just rip zodbcode et al out of a new version of zcmlfiles? Sure. That's what Jim wanted to do as well, as announced in another thread. I'd just like to remove the versions pins *after* we have done so ;) Hanno

1 0

Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production.
by Tres Seaver 07 Jul '09

07 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote: > Log message for revision 101616: > Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production. Shouldn't we just rip zodbcode et al out of a new version of zcmlfiles? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKUpdu+gerLs4ltQ4RAiTyAKDbLJUCqtzAr60SJbtrZIw21GXGJQCfTbB5 tJsphRvfvTBTU/ejJX/OGFk= =K7Li -----END PGP SIGNATURE-----

2 1

zope.html with FCKEditor security fix
by Benji York 06 Jul '09

06 Jul '09

Version 1.2.0 of zope.html has just been released. It includes the security fix release of FCKEditor (2.6.4.1) which addresses http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2265. -- Benji York Senior Software Engineer Zope Corporation

1 0

Re: [Zope-dev] [Distutils] Where is the setuptools source repository?
by Jim Fulton 06 Jul '09

06 Jul '09

Switching to zope-dev. On Jul 2, 2009, at 10:40 AM, Chris Withers wrote: > Jim Fulton wrote: >> buildout works fine. The problem is the zope.testing test runner, >> which will find tests in your eggs directory if your buildout is in >> your software path. > > I'm safe from this one, since I store all my eggs in ~/buildout-eggs > as specified in my ~/.buildout/default.cfg. > > However, the same problem occurs with the contents of the build > directory :-( It is really rather shallow and should be easy to fix. The issue is that the test finder will descend into directories that don't have __init__.py files, and shouldn't. Jim -- Jim Fulton Zope Corporation

2 2

Re: [Zope-dev] [Distutils] Where is the setuptools source repository?
by Christian Theune 04 Jul '09

04 Jul '09

On Sat, 2009-07-04 at 11:25 -0400, Barry Warsaw wrote: > On Jul 4, 2009, at 6:30 AM, Christian Theune wrote: > > > It was shallow after understanding it ... ;) > > > > The test runner already tried to avoid those directories, except there > > wasn't a test for this and obviously it was bound to be broken. > > > > It's fixed on the testrunner trunk now. > > Very cool, thanks Christian. I'm already using 'src' in most of my > active packages, but I'll try it out and see. Is this fix in > zope.testing 3.7.6? Nope, I didn't care to cut a release right away. If you can't/don't want to use the trunk I'd be happy to cut one. Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development

1 0

A suggestion for changing exception handler when loading 'c' optimisations to make modules more friendly for GAE
by Tim Hoffman 03 Jul '09

03 Jul '09

Hi all Can I make a suggestion that would make a couple of modules more gae friendly ;-) zope.interface and zope.i18nmessageid have 'c' optimisations which obviously don't work under app engine. When these modules are imported you get the following exception. gae/1.333250465889549129/zope/i18nmessageid/_zope_i18nmessageid_message.py", line 6, in __bootstrap__ imp.load_dynamic(__name__,__file__) File "/base/python_dist/lib/python2.5/py_imp.py", line 116, in load_dynamic raise NotImplementedError('This function is not supported on App Engine.') Unfortunately the code (in this case in zope.i18nmessageid.Message) does the following which doesn't deal with the Exception raised by the app engine runtime. try: from _zope_i18nmessageid_message import Message except ImportError: pass To make it more "gae friendly" I think we should change these occurrences to try: from _zope_i18nmessageid_message import Message except ImportError, NotImplementedError: pass Regards Tim

6 12