From matt.halstead at gmail.com Thu Apr 12 06:26:45 2007 From: matt.halstead at gmail.com (Matt) Date: Thu, 12 Apr 2007 16:26:45 +1200 Subject: [z3-five] file location in ViewPageTemplateFile Message-ID: <60d4509f0704112126r41530bbj6dbc127fe6e0466d@mail.gmail.com> Hi, I have the following in a doctest >>> from Products.Five.browser import BrowserView >>> from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile >>> from Products import myproduct >>> class ViewBlah(BrowserView): ... ... __call__ = ViewPageTemplateFile('tests/viewblah.pt', rdftool.__dict__) >>> where viewblah.pt's path is: $INSTANCEHOME/Products/myproduct/tests/viewblah.pt While this does end up finding and binding the template viewblah.pt to ViewBlah, it doesn't look like the way this should be done. My current environment is Zope 2.9.6 and Five 1.4.2 cheers Matt From matt.halstead at auckland.ac.nz Thu Apr 12 06:28:16 2007 From: matt.halstead at auckland.ac.nz (Matt ) Date: Thu, 12 Apr 2007 16:28:16 +1200 Subject: [z3-five] Fwd: file location in ViewPageTemplateFile [correction] Message-ID: <60d4509f0704112128g7c5ac458y94a663b27c2a5307@mail.gmail.com> Hi, I have the following in a doctest >>> from Products.Five.browser import BrowserView >>> from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile >>> from Products import myproduct >>> class ViewBlah(BrowserView): ... ... __call__ = ViewPageTemplateFile('tests/viewblah.pt', myproduct.__dict__) >>> where viewblah.pt's path is: $INSTANCEHOME/Products/myproduct/tests/viewblah.pt While this does end up finding and binding the template viewblah.pt to ViewBlah, it doesn't look like the way this should be done. My current environment is Zope 2.9.6 and Five 1.4.2 cheers Matt From me at rpatterson.net Fri Apr 13 07:42:03 2007 From: me at rpatterson.net (Ross Patterson) Date: Thu, 12 Apr 2007 22:42:03 -0700 Subject: [z3-five] five.intid compatible with five.localsitemanager Message-ID: <87tzvkrftg.fsf@superfluity.lefae.org> I need five.intid in Plone 3.0 so I started a branch that is compatible with five.localsitemanager as is used in Plone 3.0/Zope 2.10: http://svn.plone.org/svn/collective/five.intid/branch/localsitemanager/ Is there any interest in integrating this into five.intid/trunk? If so I'd be happy to factor out the necessary bits and make them conditional on successful import of five.localsitemanager falling back to the Zope 2.9/non-localsitemanager bits as appropriate. If not, can anyone reccomend an alternate approach that doesn't involve maintaining a separate branch? Ross From philipp at weitershausen.de Fri Apr 13 13:51:57 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Fri, 13 Apr 2007 13:51:57 +0200 Subject: [z3-five] five.intid compatible with five.localsitemanager In-Reply-To: <87tzvkrftg.fsf@superfluity.lefae.org> References: <87tzvkrftg.fsf@superfluity.lefae.org> Message-ID: <461F6EDD.8030401@weitershausen.de> Ross Patterson wrote: > I need five.intid in Plone 3.0 so I started a branch that is compatible > with five.localsitemanager as is used in Plone 3.0/Zope 2.10: > > http://svn.plone.org/svn/collective/five.intid/branch/localsitemanager/ Btw, I wonder if this project could perhaps move to svn.zope.org, being in the "five" namespace and not having to do anything with Plone per se. > Is there any interest in integrating this into five.intid/trunk? If so > I'd be happy to factor out the necessary bits and make them conditional > on successful import of five.localsitemanager falling back to the Zope > 2.9/non-localsitemanager bits as appropriate. I would argue that depending on five.localsitemanager as an egg is an absolutely acceptable solution. > If not, can anyone reccomend an alternate approach that doesn't involve > maintaining a separate branch? Merging to trunk and making a release? :) -- http://worldcookery.com -- Professional Zope documentation and training From me at rpatterson.net Fri Apr 13 17:44:45 2007 From: me at rpatterson.net (Ross Patterson) Date: Fri, 13 Apr 2007 08:44:45 -0700 Subject: [z3-five] five.intid compatible with five.localsitemanager References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> Message-ID: <878xcwqnwy.fsf@superfluity.lefae.org> whit writes: > Ross, let me know if there is anything I can do to help you with a > release(or if you need me to make one). fianc? is out of town this > weekend and I'm going to dedicate an evening or two to stuff like > this. Firstly, I just want to reiterate that merging this branch as it currently is will *break* five.intid without five.localsitemanager and it looks like five.localsitemanager isn't compatible with Zope 2.10. So are you giving me the go ahead for that? Or are you giving me the go ahead to factor out the bits that are dependent and making them dependent on a conditional of successful import of five.localsitemanager? IOW, do you want to maintain Zope 2.9 compatibility? try: import five.localsitemanager except ImportError: USE_LSM = False else: USE_LSM = True ... if USE_LSM: make_objectmanager_site(...) else: enableLocalSiteHook(...) I'm not up to speed on eggs yet and don't have the time to get up to speed just now. So I'll do what I can to setup the egg dependency on five.localsitemanager but if you could test the egg specific bits for me, that would be great. Other than that I can cut a release myself once I get your final word. Thanks! Ross From faassen at startifact.com Fri Apr 13 19:26:41 2007 From: faassen at startifact.com (Martijn Faassen) Date: Fri, 13 Apr 2007 19:26:41 +0200 Subject: [z3-five] five.intid compatible with five.localsitemanager In-Reply-To: <461F9616.8070008@openplans.org> References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> Message-ID: <461FBD51.1040109@startifact.com> whit wrote: [snip] > I take this opportunity to bitch that I hate > viewcvs, the collective has trac and normal http browsing and often is > faster than zope's repository and is not plone specific. And having to > use ssh + svn sucks for creating developer bundles or doing developer > checkout view easy_install. who should I be sending mail to at the ZF? Your ZF developer board delegate is here and is listening. :) Are you volunteering to do the work of setting up a trac for zope.org? We clearly have part of the functionality of Trac on launchpad, but I think for instance a trac timeline and browsing facility would still be very useful. Moving the current infrastructure over to some new system would take quite a bit of doing (and not only technically), but if we got volunteers to help, we might actually get the ship in motion. Regards, Martijn From k_vertigo at objectrealms.net Fri Apr 13 20:44:25 2007 From: k_vertigo at objectrealms.net (Kapil Thangavelu) Date: Fri, 13 Apr 2007 14:44:25 -0400 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager In-Reply-To: <878xcwqnwy.fsf@superfluity.lefae.org> References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> <878xcwqnwy.fsf@superfluity.lefae.org> Message-ID: could explain why this change is nesc. to make five.intid work with five.lsm? -kapil On Fri, 13 Apr 2007 11:44:45 -0400, Ross Patterson wrote: > whit writes: > >> Ross, let me know if there is anything I can do to help you with a >> release(or if you need me to make one). fianc? is out of town this >> weekend and I'm going to dedicate an evening or two to stuff like >> this. > > Firstly, I just want to reiterate that merging this branch as it > currently is will *break* five.intid without five.localsitemanager and > it looks like five.localsitemanager isn't compatible with Zope 2.10. So > are you giving me the go ahead for that? Or are you giving me the go > ahead to factor out the bits that are dependent and making them > dependent on a conditional of successful import of > five.localsitemanager? IOW, do you want to maintain Zope 2.9 > compatibility? > > From d.w.morriss at gmail.com Fri Apr 13 20:55:54 2007 From: d.w.morriss at gmail.com (whit) Date: Fri, 13 Apr 2007 13:55:54 -0500 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager In-Reply-To: References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> <878xcwqnwy.fsf@superfluity.lefae.org> Message-ID: Kapil Thangavelu wrote: > could explain why this change is nesc. to make five.intid work with > five.lsm? > > -kapil > > On Fri, 13 Apr 2007 11:44:45 -0400, Ross Patterson > wrote: > >> whit writes: >> >>> Ross, let me know if there is anything I can do to help you with a >>> release(or if you need me to make one). fianc? is out of town this >>> weekend and I'm going to dedicate an evening or two to stuff like >>> this. >> Firstly, I just want to reiterate that merging this branch as it >> currently is will *break* five.intid without five.localsitemanager and >> it looks like five.localsitemanager isn't compatible with Zope 2.10. So >> are you giving me the go ahead for that? Or are you giving me the go >> ahead to factor out the bits that are dependent and making them >> dependent on a conditional of successful import of >> five.localsitemanager? IOW, do you want to maintain Zope 2.9 >> compatibility? >> >> I asked ross to merge on a branch, and we will try to maintain 2.9 compat and have releases to reflect this. -w -- ------ d. whit morriss ------ - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 From d.w.morriss at gmail.com Fri Apr 13 20:56:43 2007 From: d.w.morriss at gmail.com (whit) Date: Fri, 13 Apr 2007 13:56:43 -0500 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager In-Reply-To: References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> <878xcwqnwy.fsf@superfluity.lefae.org> Message-ID: I'm guessing he want to install the intid utility with full lsm capabilities. -w -- ------ d. whit morriss ------ - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 From philipp at weitershausen.de Sun Apr 15 12:30:17 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Sun, 15 Apr 2007 12:30:17 +0200 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager In-Reply-To: <461F9616.8070008@openplans.org> References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> Message-ID: On 13 Apr 2007, at 16:39 , whit wrote: > since I own five.intid, I take this opportunity to bitch that I > hate viewcvs, the collective has trac and normal http browsing and > often is faster than zope's repository and is not plone specific. > And having to use ssh + svn sucks for creating developer bundles or > doing developer checkout view easy_install. who should I be > sending mail to at the ZF? I think Martijn is in charge of technical things like this. I would hope that volunteers who would like to install trac etc. will soon be giving access. There are actually some benefits to the current svn +ssh infrastructure and since we have an svn:// server for anonymous checkouts, I don't so much see the problem here. Sure, changing stuff in externals in-place doesn't work, but typically you're not supposed to do that anyway (need to run tests, etc.). > all bitching aside, +1 let's move it ;) what needs to happen here? Are you a Zope committer? If so, just check it in. If you want to preserve version history, we'll need a dump of the relevant SVN revisions and somebody at ZF/ZC will have to import them. From optilude at gmx.net Sun Apr 15 17:02:14 2007 From: optilude at gmx.net (Martin Aspeli) Date: Sun, 15 Apr 2007 16:02:14 +0100 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager In-Reply-To: <87odlsovlo.fsf@superfluity.lefae.org> References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> <878xcwqnwy.fsf@superfluity.lefae.org> <87odlsovlo.fsf@superfluity.lefae.org> Message-ID: Ross Patterson wrote: > "Kapil Thangavelu" writes: > >> could explain why this change is nesc. to make five.intid work with >> five.lsm? > > FiveSiteManager doesn't cooperate with the resolution order of > PersistentComponents. For example a FiveSiteManagers utility registry > has no __bases__ attribute which raises an error in > zope/interface/ro.py:60. So if a site that uses localsitemanager (such > as Plone) is instantiated *after* the FiveSiteManager has been setup at > the application root by add_intids, then this error occurs. Is that not just a bug in five.lsm? > Also, the registerUtility call in add_intids uses the old API and so > that raises an error when add_intids tries to register the IntIds > utility for a localsitemanager. Yes, you'd need to port the code to Zope 2.10-style persistent components (which is easy). I did think and hope that five.lsm would play with this, though. Martin From philipp at weitershausen.de Sun Apr 15 18:36:31 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Sun, 15 Apr 2007 18:36:31 +0200 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager In-Reply-To: References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> <878xcwqnwy.fsf@superfluity.lefae.org> <87odlsovlo.fsf@superfluity.lefae.org> Message-ID: <4622548F.7030506@weitershausen.de> Martin Aspeli wrote: > Ross Patterson wrote: >> "Kapil Thangavelu" writes: >> >>> could explain why this change is nesc. to make five.intid work with >>> five.lsm? >> FiveSiteManager doesn't cooperate with the resolution order of >> PersistentComponents. For example a FiveSiteManagers utility registry >> has no __bases__ attribute which raises an error in >> zope/interface/ro.py:60. So if a site that uses localsitemanager (such >> as Plone) is instantiated *after* the FiveSiteManager has been setup at >> the application root by add_intids, then this error occurs. > > Is that not just a bug in five.lsm? It certainly smells that way. >> Also, the registerUtility call in add_intids uses the old API and so >> that raises an error when add_intids tries to register the IntIds >> utility for a localsitemanager. > > Yes, you'd need to port the code to Zope 2.10-style persistent > components (which is easy). I did think and hope that five.lsm would > play with this, though. It sure does. -- http://worldcookery.com -- Professional Zope documentation and training From me at rpatterson.net Sun Apr 15 19:41:07 2007 From: me at rpatterson.net (Ross Patterson) Date: Sun, 15 Apr 2007 10:41:07 -0700 Subject: [z3-five] [Framework-Team] Re: five.intid compatible with five.localsitemanager References: <87tzvkrftg.fsf@superfluity.lefae.org> <461F6EDD.8030401@weitershausen.de> <461F9616.8070008@openplans.org> <878xcwqnwy.fsf@superfluity.lefae.org> <87odlsovlo.fsf@superfluity.lefae.org> Message-ID: <87abx9mt05.fsf@superfluity.lefae.org> Martin Aspeli writes: > Ross Patterson wrote: >> "Kapil Thangavelu" writes: >> >>> could explain why this change is nesc. to make five.intid work with >>> five.lsm? >> >> FiveSiteManager doesn't cooperate with the resolution order of >> PersistentComponents. For example a FiveSiteManagers utility registry >> has no __bases__ attribute which raises an error in >> zope/interface/ro.py:60. So if a site that uses localsitemanager (such >> as Plone) is instantiated *after* the FiveSiteManager has been setup at >> the application root by add_intids, then this error occurs. > > Is that not just a bug in five.lsm? Well I don't know. As far as I can tell zope.interface.adapter base registry code supports resolution orders, so I thought it was a bug in FiveSiteManager *not* to support it. Are there any tests for FiveSiteManager to verify that it serves properly as a base registry for other registries? >> Also, the registerUtility call in add_intids uses the old API and so >> that raises an error when add_intids tries to register the IntIds >> utility for a localsitemanager. > > Yes, you'd need to port the code to Zope 2.10-style persistent > components (which is easy). I did think and hope that five.lsm would > play with this, though. Yes, five.lsm does play with it. It was five.intid that used the old API. Maybe I'm misunderstanding you here? Ross From optilude at gmx.net Tue Apr 17 02:03:51 2007 From: optilude at gmx.net (Martin Aspeli) Date: Tue, 17 Apr 2007 01:03:51 +0100 Subject: [z3-five] ZCML security declarations and properties Message-ID: Hi guys, I have an interface that defines various properties: class IFoo(Interface): bar = schema.TextLine(...) class Foo(SimpleItem): implements(IBar) bar = property(...) I then have this in ZCML: Phone number in a page ViewPageTemplateFile in a Z3 view (i.e. trusted code), I get: Unauthorized: You are not allowed to access 'bar' in this context This is with verbose-security on, but not much help there... What am I missing here? Why is this happening even in trusted code? Martin From tseaver at palladion.com Tue Apr 17 04:39:34 2007 From: tseaver at palladion.com (Tres Seaver) Date: Mon, 16 Apr 2007 22:39:34 -0400 Subject: [z3-five] ZCML security declarations and properties In-Reply-To: References: Message-ID: <46243366.7050807@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: > Hi guys, > > I have an interface that defines various properties: > > class IFoo(Interface): > > bar = schema.TextLine(...) > > class Foo(SimpleItem): > implements(IBar) > > bar = property(...) > > I then have this in ZCML: > > permission="zope2.View" > interface=".interfaces.IFoo > /> > permission="cmf.ModifyPortalContent" > set_schema=".interfaces.Foo > /> > > > However, if I try to do > > Phone number > > in a page ViewPageTemplateFile in a Z3 view (i.e. trusted code), I get: > > Unauthorized: You are not allowed to access 'bar' in this context > > This is with verbose-security on, but not much help there... > > What am I missing here? Why is this happening even in trusted code? 'getPhone' is not declared as being part of the interface to which you grant permission in the ZCML; your other error is assuming that a ZPT is trusted code. You need to grant permissions for *all* attributes / methods you access through ZPT, *except* those bound into the top-level namespace (like 'options', 'request' etc.) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJDNm+gerLs4ltQ4RArh5AJ0XVqJtzb80izqgbZZ8s4Gs/e3HVQCgqyBe M1yfmSvl1xT8mb524Ws9yKo= =zBOg -----END PGP SIGNATURE----- From optilude at gmx.net Tue Apr 17 09:24:44 2007 From: optilude at gmx.net (Martin Aspeli) Date: Tue, 17 Apr 2007 08:24:44 +0100 Subject: [z3-five] ZCML security declarations and properties In-Reply-To: <46243366.7050807@palladion.com> References: <46243366.7050807@palladion.com> Message-ID: Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Aspeli wrote: >> Hi guys, >> >> I have an interface that defines various properties: >> >> class IFoo(Interface): >> >> bar = schema.TextLine(...) >> >> class Foo(SimpleItem): >> implements(IBar) >> >> bar = property(...) >> >> I then have this in ZCML: >> >> > > permission="zope2.View" >> interface=".interfaces.IFoo >> /> >> > permission="cmf.ModifyPortalContent" >> set_schema=".interfaces.Foo >> /> >> >> >> However, if I try to do >> >> Phone number >> >> in a page ViewPageTemplateFile in a Z3 view (i.e. trusted code), I get: >> >> Unauthorized: You are not allowed to access 'bar' in this context >> >> This is with verbose-security on, but not much help there... >> >> What am I missing here? Why is this happening even in trusted code? > > 'getPhone' is not declared as being part of the interface to which you > grant permission in the ZCML; Sorry, I'm being a muppet. The code I pasted was the workaround (I used a method). This is the code that gives the error: Bar (I've simplified my code down to Foo and bar, obviously, it had to do with a phone number to start with). 'bar' here is in the interface. I *think* the key point here is that 'bar' is a Python property, not a method, but I'm not sure. > your other error is assuming that a ZPT > is trusted code. You need to grant permissions for *all* attributes / > methods you access through ZPT, *except* those bound into the top-level > namespace (like 'options', 'request' etc.) I'm talking about a ZPT bound to a Z3 view with Products.Five.browser.pagetemplatefile.ViewPageTemplateFile. In my understanding, these are trusted code, at least I'm able to do all kinds of otherwise "insecure" things inside them, but not access this bit of my context content object. e.g. class FooView(BrowserView): __call__ = ViewPageTemplateFile('foo.pt') and the HTML Bar goes inside foo.pt. Martin From tseaver at palladion.com Tue Apr 17 16:37:29 2007 From: tseaver at palladion.com (Tres Seaver) Date: Tue, 17 Apr 2007 10:37:29 -0400 Subject: [z3-five] ZCML security declarations and properties In-Reply-To: References: <46243366.7050807@palladion.com> Message-ID: <4624DBA9.5020604@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Martin Aspeli wrote: >>> Hi guys, >>> >>> I have an interface that defines various properties: >>> >>> class IFoo(Interface): >>> >>> bar = schema.TextLine(...) >>> >>> class Foo(SimpleItem): >>> implements(IBar) >>> >>> bar = property(...) >>> >>> I then have this in ZCML: >>> >>> >> >> permission="zope2.View" >>> interface=".interfaces.IFoo >>> /> >>> >> permission="cmf.ModifyPortalContent" >>> set_schema=".interfaces.Foo >>> /> >>> >>> >>> However, if I try to do >>> >>> Phone number >>> >>> in a page ViewPageTemplateFile in a Z3 view (i.e. trusted code), I get: >>> >>> Unauthorized: You are not allowed to access 'bar' in this context >>> >>> This is with verbose-security on, but not much help there... >>> >>> What am I missing here? Why is this happening even in trusted code? >> 'getPhone' is not declared as being part of the interface to which you >> grant permission in the ZCML; > > Sorry, I'm being a muppet. The code I pasted was the workaround (I used > a method). This is the code that gives the error: > > Bar > > (I've simplified my code down to Foo and bar, obviously, it had to do > with a phone number to start with). 'bar' here is in the interface. > > I *think* the key point here is that 'bar' is a Python property, not a > method, but I'm not sure. Can you examine your class in the debugger, and look at its __dict__? The interesting keys are going to be '__ac_permissions__' and 'bar__roles__' (if that one exists). >> your other error is assuming that a ZPT >> is trusted code. You need to grant permissions for *all* attributes / >> methods you access through ZPT, *except* those bound into the top-level >> namespace (like 'options', 'request' etc.) > > I'm talking about a ZPT bound to a Z3 view with > Products.Five.browser.pagetemplatefile.ViewPageTemplateFile. In my > understanding, these are trusted code, at least I'm able to do all kinds > of otherwise "insecure" things inside them, but not access this bit of > my context content object. You are correct that the VPTF is trusted code -- my bad. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJNup+gerLs4ltQ4RAoeMAJwKdnv7WSLLGfHNzWDrgQDv/kx9zwCfd0Ib RBX7SCoAvmA/9z5hgnRxVls= =cVe4 -----END PGP SIGNATURE----- From optilude at gmx.net Tue Apr 17 23:32:28 2007 From: optilude at gmx.net (Martin Aspeli) Date: Tue, 17 Apr 2007 22:32:28 +0100 Subject: [z3-five] ZCML security declarations and properties In-Reply-To: <4624DBA9.5020604@palladion.com> References: <46243366.7050807@palladion.com> <4624DBA9.5020604@palladion.com> Message-ID: Tres Seaver wrote: > Can you examine your class in the debugger, and look at its __dict__? > The interesting keys are going to be '__ac_permissions__' and > 'bar__roles__' (if that one exists). __ac_permissions__ has 'bar' in the list for 'View' (and nothing else). bar__roles__ is: ['Anonymous', 'Manager', 'Reviewer', 'Reader', 'Editor', 'Anonymous', 'Manager', 'Reviewer', 'Reader', 'Editor', 'Reader', 'Manager', 'Anonymous'] Apart from the repetition, that is what I'd expect. >>> your other error is assuming that a ZPT >>> is trusted code. You need to grant permissions for *all* attributes / >>> methods you access through ZPT, *except* those bound into the top-level >>> namespace (like 'options', 'request' etc.) >> I'm talking about a ZPT bound to a Z3 view with >> Products.Five.browser.pagetemplatefile.ViewPageTemplateFile. In my >> understanding, these are trusted code, at least I'm able to do all kinds >> of otherwise "insecure" things inside them, but not access this bit of >> my context content object. > > You are correct that the VPTF is trusted code -- my bad. So then why does this matter at all? /me scratches head... Martin From optilude at gmx.net Tue Apr 17 23:42:36 2007 From: optilude at gmx.net (Martin Aspeli) Date: Tue, 17 Apr 2007 22:42:36 +0100 Subject: [z3-five] ZCML security declarations and properties In-Reply-To: References: <46243366.7050807@palladion.com> <4624DBA9.5020604@palladion.com> Message-ID: Martin Aspeli wrote: > Tres Seaver wrote: > >> Can you examine your class in the debugger, and look at its __dict__? >> The interesting keys are going to be '__ac_permissions__' and >> 'bar__roles__' (if that one exists). > > __ac_permissions__ has 'bar' in the list for 'View' (and nothing else). > bar__roles__ is: > > ['Anonymous', > 'Manager', > 'Reviewer', > 'Reader', > 'Editor', > 'Anonymous', > 'Manager', > 'Reviewer', > 'Reader', > 'Editor', > 'Reader', > 'Manager', > 'Anonymous'] > > Apart from the repetition, that is what I'd expect. > >>>> your other error is assuming that a ZPT >>>> is trusted code. You need to grant permissions for *all* attributes / >>>> methods you access through ZPT, *except* those bound into the top-level >>>> namespace (like 'options', 'request' etc.) >>> I'm talking about a ZPT bound to a Z3 view with >>> Products.Five.browser.pagetemplatefile.ViewPageTemplateFile. In my >>> understanding, these are trusted code, at least I'm able to do all kinds >>> of otherwise "insecure" things inside them, but not access this bit of >>> my context content object. >> You are correct that the VPTF is trusted code -- my bad. > > So then why does this matter at all? Mmm... If I do this, it's okay:
Hi, In an interface I have an Attribute: bookinglist = Attribute("List of individual Bookings") Now when starting Zope, I get a warning: WARNING Init Class Products.Five.metaclass.BookingListView \ has a security declaration for nonexistent method 'bookinglist' Everything works as expected as far as I can see, so it does not look like a real problem. But is there a way to get rid of this warning? Ah, the warning gets throws at the end of lib/python/App/class_init.py as it can't find an attribute with the name 'bookinglist' in that class. And that is correct as I set that in the __init__.py of the view class, so at Zope startup time it is not known. So: should all Attributes of a browser view be set in the class definition outside of the __init__()? Well, all Attributes that are indicated by the Interface at least. Correct? It gets rid of the warning anyway and looks like good practice. -- Maurits van Rees | http://maurits.vanrees.org/ [NL] Work | http://zestsoftware.nl/ "Do not worry about your difficulties in computers, I can assure you mine are still greater." From tseaver at palladion.com Wed Apr 18 17:43:09 2007 From: tseaver at palladion.com (Tres Seaver) Date: Wed, 18 Apr 2007 11:43:09 -0400 Subject: [z3-five] Attribute gives: security declaration for nonexistent method In-Reply-To: References: Message-ID: <46263C8D.1050907@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maurits van Rees wrote: > Hi, > > In an interface I have an Attribute: > > bookinglist = Attribute("List of individual Bookings") > > Now when starting Zope, I get a warning: > > WARNING Init Class Products.Five.metaclass.BookingListView \ > has a security declaration for nonexistent method 'bookinglist' > > Everything works as expected as far as I can see, so it does not look > like a real problem. But is there a way to get rid of this warning? > > Ah, the warning gets throws at the end of lib/python/App/class_init.py > as it can't find an attribute with the name 'bookinglist' in that > class. And that is correct as I set that in the __init__.py of the > view class, so at Zope startup time it is not known. > > So: should all Attributes of a browser view be set in the class > definition outside of the __init__()? Well, all Attributes that are > indicated by the Interface at least. Correct? > > It gets rid of the warning anyway and looks like good practice. It also makes it possible to verify the conformance of the class to the interface:: >>> from zope.interface.verify import verifyClass >>> from mypackage.interfaces import IFoo >>> from mypackage.foo import Foo >>> verifyClass(IFoo, Foo) # doesn't raise An added benefit is that setting defaults at the class level seems more readable than setting them in the __init__, Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at 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 iD8DBQFGJjyN+gerLs4ltQ4RAmV4AJ9fByNoslrbb3/5o0MsiMzgQ03KqQCg2M8B rhvFt/vswMsOHp2hmmmjKI8= =IMWq -----END PGP SIGNATURE----- From faassen at startifact.com Fri May 4 21:30:12 2007 From: faassen at startifact.com (Martijn Faassen) Date: Fri, 04 May 2007 21:30:12 +0200 Subject: [z3-five] FiveException in Zope 2 trunk? Message-ID: Hi there, I can find some discussion from last year between Sidnei and Philipp about integrating FiveException into the Zope 2 trunk. Has this happened yet? Regards, Martijn From sidnei at enfoldsystems.com Fri May 4 23:01:11 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Fri, 4 May 2007 18:01:11 -0300 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: Message-ID: On 5/4/07, Martijn Faassen wrote: > Hi there, > > I can find some discussion from last year between Sidnei and Philipp > about integrating FiveException into the Zope 2 trunk. Has this happened > yet? Timely question my friend. There's a working patch against Zope 2.9, with several tests. Just waiting for some good soul to come and merge it in ;) http://www.zope.org/Collectors/Zope/2315 We are using this in production. There's only one issue which I've hit today, if the exception view fails to render it doesn't get logged, since in the patch renders the view *after* it logged to the error_log object. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From optilude at gmx.net Fri May 4 23:10:50 2007 From: optilude at gmx.net (Martin Aspeli) Date: Fri, 04 May 2007 22:10:50 +0100 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: Message-ID: Martijn Faassen wrote: > Hi there, > > I can find some discussion from last year between Sidnei and Philipp > about integrating FiveException into the Zope 2 trunk. Has this happened > yet? Don't think so, but Plone 3 ships with a patch (in plone.app.linkintegrity) which basically puts it in. We'd love to rip the patch out and have it trunk. Martin From optilude at gmx.net Sun May 6 21:44:11 2007 From: optilude at gmx.net (Martin Aspeli) Date: Sun, 06 May 2007 20:44:11 +0100 Subject: [z3-five] Templates in views and path expressions Message-ID: Hi guys, This is driving me up the wall. I have a content class: class Project(Container): implements(IProject) portal_type = "Project" title = u"" description = u"" managers = [] members = [] workflow_policy = None addable_types = [] Protected with: Then, I have a view: And a template:

When I try to access this, I get: Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module Products.PDBDebugMode.pdbzope.runcall, line 60, in pdb_runcall Module ZPublisher.Publish, line 42, in call_object Module Products.Five.browser.metaconfigure, line 416, in __call__ Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.PageTemplates.PageTemplateFile, line 129, in _exec Module Products.PageTemplates.PageTemplate, line 89, in pt_render Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ ... Module Products.PageTemplates.Expressions, line 199, in evaluateText Module zope.tales.tales, line 696, in evaluate - URL: index - Line 13, Column 4 - Expression: - Names: {'container': , 'context': , 'default': , 'here': , 'loop': {}, 'nothing': None, 'options': {'args': (,)}, 'repeat': , 'request': , 'root': , 'template': , 'traverse_subpath': [], 'user': , 'view': , 'views': } Module zope.tales.expressions, line 217, in __call__ Module Products.PageTemplates.Expressions, line 131, in _eval Module zope.tales.expressions, line 124, in _eval Module Products.PageTemplates.Expressions, line 80, in boboAwareZopeTraverse Module OFS.Traversable, line 301, in restrictedTraverse Module OFS.Traversable, line 236, in unrestrictedTraverse - __traceback_info__: ([], 'title') Module AccessControl.ImplPython, line 563, in validate Module AccessControl.ImplPython, line 454, in validate Module AccessControl.ImplPython, line 808, in raiseVerbose Unauthorized: Your user account is defined outside the context of the object being accessed. Access to 'title' of (Project at /test/workspace-one) denied. Your user account, admin, exists at /acl_users. Access requires one of the following roles: ['Contributor', 'Editor', 'Manager', 'Owner', 'Reader']. I think this is because it's trying to security check 'title'. In ImplPython.py, with verbose security on, this is the one that's failing: def verifyAcquisitionContext(user, object, object_roles=None): """Mimics the relevant section of User.allowed(). Returns true if the object is in the context of the user's user folder. """ ufolder = aq_parent(user) ucontext = aq_parent(ufolder) if ucontext is not None: if object is None: # This is a strange rule, though # it doesn't cause any security holes. SDH return 1 if not hasattr(object, 'aq_inContextOf'): if hasattr(object, 'im_self'): # This is a method. Grab its self. object=object.im_self if not hasattr(object, 'aq_inContextOf'): # object is not wrapped, therefore we # can't determine context. # Fail the access attempt. Otherwise # this would be a security hole. -------> return None if not object.aq_inContextOf(ucontext, 1): if 'Shared' in object_roles: # Old role setting. Waaa object_roles=user._shared_roles(object) if 'Anonymous' in object_roles: return 1 return None # Note that if the user were not wrapped, it would # not be possible to determine the user's context # and this method would return 1. # However, as long as user folders always return # wrapped user objects, this is safe. return 1 With a breakpoint there, "object" is the string u"Some title", i.e. the value of the title attribute. I can make this work by doing this:

Or, I can make it work by leaving the context/title syntax in the template, but commenting out the ... bit. So, first of all, it seems that: - ViewPageTemplateFile's in a browser view are doing restricted, rather than unrestricted traversals - The directive doesn't seem to work properly on simple properties Are these bugs? Are my expectations unreasonable? What are the consequences of not having a directive setting permissions on the content type? Cheers, Martin From tseaver at palladion.com Mon May 7 03:45:08 2007 From: tseaver at palladion.com (Tres Seaver) Date: Sun, 06 May 2007 21:45:08 -0400 Subject: [z3-five] Templates in views and path expressions In-Reply-To: References: Message-ID: <463E84A4.1010802@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: > Hi guys, > > This is driving me up the wall. > > I have a content class: > > class Project(Container): > implements(IProject) > portal_type = "Project" > > title = u"" > description = u"" > managers = [] > members = [] > workflow_policy = None > addable_types = [] > > Protected with: > > class=".content.Project" > meta_type="b-org Project" > permission="borg.project.AddProject" > addview="borg.project.Project" > icon="borg_project_icon.png" > /> > > component=".content.projectFactory" > name="borg.project.Project" > /> > > > permission="zope2.View" > interface=".interfaces.IProject" > /> > permission="cmf.ModifyPortalContent" > set_schema=".interfaces.IProject" > /> > > > Then, I have a view: > > > And a template: > >

> > When I try to access this, I get: > > Traceback (innermost last): > Module ZPublisher.Publish, line 119, in publish > Module ZPublisher.mapply, line 88, in mapply > Module Products.PDBDebugMode.pdbzope.runcall, line 60, in pdb_runcall > Module ZPublisher.Publish, line 42, in call_object > Module Products.Five.browser.metaconfigure, line 416, in __call__ > Module Shared.DC.Scripts.Bindings, line 313, in __call__ > Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec > Module Products.PageTemplates.PageTemplateFile, line 129, in _exec > Module Products.PageTemplates.PageTemplate, line 89, in pt_render > Module zope.pagetemplate.pagetemplate, line 117, in pt_render > Module zope.tal.talinterpreter, line 271, in __call__ > ... > Module Products.PageTemplates.Expressions, line 199, in evaluateText > Module zope.tales.tales, line 696, in evaluate > - URL: index > - Line 13, Column 4 > - Expression: > - Names: > {'container': , > 'context': , > 'default': , > 'here': , > 'loop': {}, > 'nothing': None, > 'options': {'args': ( from > /Users/optilude/Development/Plone/Code/Products/borg/ng/borg.project/borg/project/browser/project.pt > object at 0x6835410>,)}, > 'repeat': at 0x76c8d50>, > 'request': URL=http://localhost:8080/test/workspace-one/@@view>, > 'root': , > 'template': , > 'traverse_subpath': [], > 'user': , > 'view': /Users/optilude/Development/Plone/Code/Products/borg/ng/borg.project/borg/project/browser/project.pt > object at 0x6835410>, > 'views': object at 0x68354b0>} > Module zope.tales.expressions, line 217, in __call__ > Module Products.PageTemplates.Expressions, line 131, in _eval > Module zope.tales.expressions, line 124, in _eval > Module Products.PageTemplates.Expressions, line 80, in > boboAwareZopeTraverse > Module OFS.Traversable, line 301, in restrictedTraverse > Module OFS.Traversable, line 236, in unrestrictedTraverse > - __traceback_info__: ([], 'title') > Module AccessControl.ImplPython, line 563, in validate > Module AccessControl.ImplPython, line 454, in validate > Module AccessControl.ImplPython, line 808, in raiseVerbose > Unauthorized: Your user account is defined outside the context of the > object being accessed. Access to 'title' of (Project at > /test/workspace-one) denied. Your user account, admin, exists at > /acl_users. Access requires one of the following roles: ['Contributor', > 'Editor', 'Manager', 'Owner', 'Reader']. > > I think this is because it's trying to security check 'title'. In > ImplPython.py, with verbose security on, this is the one that's failing: > > def verifyAcquisitionContext(user, object, object_roles=None): > """Mimics the relevant section of User.allowed(). > > Returns true if the object is in the context of the user's user folder. > """ > ufolder = aq_parent(user) > ucontext = aq_parent(ufolder) > if ucontext is not None: > if object is None: > # This is a strange rule, though > # it doesn't cause any security holes. SDH > return 1 > if not hasattr(object, 'aq_inContextOf'): > if hasattr(object, 'im_self'): > # This is a method. Grab its self. > object=object.im_self > if not hasattr(object, 'aq_inContextOf'): > # object is not wrapped, therefore we > # can't determine context. > # Fail the access attempt. Otherwise > # this would be a security hole. > -------> return None > if not object.aq_inContextOf(ucontext, 1): > if 'Shared' in object_roles: > # Old role setting. Waaa > object_roles=user._shared_roles(object) > if 'Anonymous' in object_roles: > return 1 > return None > # Note that if the user were not wrapped, it would > # not be possible to determine the user's context > # and this method would return 1. > # However, as long as user folders always return > # wrapped user objects, this is safe. > return 1 > > With a breakpoint there, "object" is the string u"Some title", i.e. the > value of the title attribute. > > I can make this work by doing this: > >

> > Or, I can make it work by leaving the context/title syntax in the > template, but commenting out the ... bit. > > So, first of all, it seems that: > > - ViewPageTemplateFile's in a browser view are doing restricted, > rather than unrestricted traversals This is becuase 'Products.PageTemplates.Expression.createTrustedZopeEngine' only trusts 'python:' expressions; path traversal is still governed by 'boboAwareZopeTraverse', which uses 'restrictedTraverse'. > - The directive doesn't seem to work properly on simple > properties Your context object somehow has no acquisition wrapper, and therefore cannot be verified by Zope's acquisition-based security policy. > Are these bugs? Are my expectations unreasonable? What are the > consequences of not having a directive setting permissions on > the content type? Applications which don't expose their objects to TTW-modifiable code can safely leave those declarations out; in fact, all the Five-based apps I have worked on do this, as they don't permit "skinning" or "customerization". We had a similar exchange about three weeks ago on the subject, 'ZCML security declarations and properties'. I conceded then, through failutre to read carefully enough: > You are correct that the VPTF is trusted code -- my bad. As it turns out, it is only "partially trusted." The attached patch should make them "really trusted", at least for path expressions; does it help? I haven't added any tests, although my 2.10 branch checkout does pass all tests with this change. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at 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 iD8DBQFGPoSj+gerLs4ltQ4RAioOAKDYoA66AGZszM7LTQfrn8+QN+3//ACcCwSl WchbpEPYpqzyFoFpk9d+u/I= =tL7+ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: reallyTrustedViews.patch Type: text/x-patch Size: 2869 bytes Desc: not available Url : http://codespeak.net/pipermail/z3-five/attachments/20070506/7f8a9ea8/attachment.bin From optilude at gmx.net Mon May 7 12:59:19 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 11:59:19 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463E84A4.1010802@palladion.com> References: <463E84A4.1010802@palladion.com> Message-ID: Hi Tres. >> - ViewPageTemplateFile's in a browser view are doing restricted, >> rather than unrestricted traversals > > This is becuase > 'Products.PageTemplates.Expression.createTrustedZopeEngine' only trusts > 'python:' expressions; path traversal is still governed by > 'boboAwareZopeTraverse', which uses 'restrictedTraverse'. That's bad, isn't it? >> - The directive doesn't seem to work properly on simple >> properties > > Your context object somehow has no acquisition wrapper, and therefore > cannot be verified by Zope's acquisition-based security policy. > >> Are these bugs? Are my expectations unreasonable? What are the >> consequences of not having a directive setting permissions on >> the content type? > > Applications which don't expose their objects to TTW-modifiable code can > safely leave those declarations out; in fact, all the Five-based apps I > have worked on do this, as they don't permit "skinning" or > "customerization". > > We had a similar exchange about three weeks ago on the subject, 'ZCML > security declarations and properties'. I conceded then, through > failutre to read carefully enough: > >> You are correct that the VPTF is trusted code -- my bad. > > As it turns out, it is only "partially trusted." The attached patch > should make them "really trusted", at least for path expressions; does > it help? I haven't added any tests, although my 2.10 branch checkout > does pass all tests with this change. > > > > Tres. > - -- > =================================================================== > Tres Seaver +1 540-429-0999 tseaver at 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 > > iD8DBQFGPoSj+gerLs4ltQ4RAioOAKDYoA66AGZszM7LTQfrn8+QN+3//ACcCwSl > WchbpEPYpqzyFoFpk9d+u/I= > =tL7+ > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------ > > Index: lib/python/Products/PageTemplates/Expressions.py > =================================================================== > --- lib/python/Products/PageTemplates/Expressions.py (revision 75597) > +++ lib/python/Products/PageTemplates/Expressions.py (working copy) > @@ -83,6 +83,26 @@ > request=request) > return object > > +def trustedBoboAwareZopeTraverse(object, path_items, econtext): > + """Traverses a sequence of names, first trying attributes then items. > + > + This uses Zope 3 path traversal where possible and interacts > + correctly with objects providing OFS.interface.ITraversable when > + necessary (bobo-awareness). > + """ > + request = getattr(econtext, 'request', None) > + path_items = list(path_items) > + path_items.reverse() > + > + while path_items: > + name = path_items.pop() > + if OFS.interfaces.ITraversable.providedBy(object): > + object = object.unrestrictedTraverse(name) > + else: > + object = traversePathElement(object, name, path_items, > + request=request) > + return object > + > def render(ob, ns): > """Calls the object, possibly a document template, or just returns > it if not callable. (From DT_Util.py) > @@ -108,11 +128,13 @@ > > class ZopePathExpr(PathExpr): > > + _TRAVERSER = staticmethod(boboAwareZopeTraverse) > + > def __init__(self, name, expr, engine): > if not expr.strip(): > expr = 'nothing' > super(ZopePathExpr, self).__init__(name, expr, engine, > - boboAwareZopeTraverse) > + self._TRAVERSER) > > # override this to support different call metrics (see bottom of > # method) and Zope 2's traversal exceptions (ZopeUndefs instead of > @@ -150,6 +172,9 @@ > return 1 > return 0 > > +class TrustedZopePathExpr(ZopePathExpr): > + _TRAVERSER = staticmethod(trustedBoboAwareZopeTraverse) > + > class SafeMapping(MultiMapping): > """Mapping with security declarations and limited method exposure. > > @@ -335,11 +360,11 @@ > return False > return ob1 == ob2 > > -def createZopeEngine(): > +def createZopeEngine(zpe=ZopePathExpr): > e = ZopeEngine() > e.iteratorFactory = PathIterator > - for pt in ZopePathExpr._default_type_names: > - e.registerType(pt, ZopePathExpr) > + for pt in zpe._default_type_names: > + e.registerType(pt, zpe) > e.registerType('string', StringExpr) > e.registerType('python', ZRPythonExpr.PythonExpr) > e.registerType('not', NotExpr) > @@ -352,7 +377,7 @@ > def createTrustedZopeEngine(): > # same as createZopeEngine, but use non-restricted Python > # expression evaluator > - e = createZopeEngine() > + e = createZopeEngine(TrustedZopePathExpr) > e.types['python'] = PythonExpr > return e > > From optilude at gmx.net Mon May 7 13:03:28 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 12:03:28 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463E84A4.1010802@palladion.com> References: <463E84A4.1010802@palladion.com> Message-ID: Hi Tres. >> - ViewPageTemplateFile's in a browser view are doing restricted, >> rather than unrestricted traversals > > This is becuase > 'Products.PageTemplates.Expression.createTrustedZopeEngine' only trusts > 'python:' expressions; path traversal is still governed by > 'boboAwareZopeTraverse', which uses 'restrictedTraverse'. That's bad, isn't it? >> - The directive doesn't seem to work properly on simple >> properties > > Your context object somehow has no acquisition wrapper, and therefore > cannot be verified by Zope's acquisition-based security policy. Strange; it derives from CMF's PortalFolder (and a few other things), so it should be acquisition-aware, and I'm invoking the view via normal traversal. What is telling you that there's no aq wrapper, specifically? >> Are these bugs? Are my expectations unreasonable? What are the >> consequences of not having a directive setting permissions on >> the content type? > > Applications which don't expose their objects to TTW-modifiable code can > safely leave those declarations out; in fact, all the Five-based apps I > have worked on do this, as they don't permit "skinning" or > "customerization". Right. I'd still prefer to have it in, though. :) I'm also unclear what the effect of base classes (e.g. PortalFolder) doing their own ClassSecrityInfo is on my own derived type, if my derived type uses neither ClassSecurityInfo directly, nor a ZCML statement. > We had a similar exchange about three weeks ago on the subject, 'ZCML > security declarations and properties'. I conceded then, through > failutre to read carefully enough: Ah yes, I knew there was a reason I had deja-vu :( >> You are correct that the VPTF is trusted code -- my bad. > > As it turns out, it is only "partially trusted." The attached patch > should make them "really trusted", at least for path expressions; does > it help? I haven't added any tests, although my 2.10 branch checkout > does pass all tests with this change. It seems to me that being "not fully trusted" is a bug, so I'd be very happy if this went in! I assume this only impacts ViewPageTemplateFiles and not regular TTW/skin layer Page Templates? Martin > ------------------------------------------------------------------------ > > Index: lib/python/Products/PageTemplates/Expressions.py > =================================================================== > --- lib/python/Products/PageTemplates/Expressions.py (revision 75597) > +++ lib/python/Products/PageTemplates/Expressions.py (working copy) > @@ -83,6 +83,26 @@ > request=request) > return object > > +def trustedBoboAwareZopeTraverse(object, path_items, econtext): > + """Traverses a sequence of names, first trying attributes then items. > + > + This uses Zope 3 path traversal where possible and interacts > + correctly with objects providing OFS.interface.ITraversable when > + necessary (bobo-awareness). > + """ > + request = getattr(econtext, 'request', None) > + path_items = list(path_items) > + path_items.reverse() > + > + while path_items: > + name = path_items.pop() > + if OFS.interfaces.ITraversable.providedBy(object): > + object = object.unrestrictedTraverse(name) > + else: > + object = traversePathElement(object, name, path_items, > + request=request) > + return object > + > def render(ob, ns): > """Calls the object, possibly a document template, or just returns > it if not callable. (From DT_Util.py) > @@ -108,11 +128,13 @@ > > class ZopePathExpr(PathExpr): > > + _TRAVERSER = staticmethod(boboAwareZopeTraverse) > + > def __init__(self, name, expr, engine): > if not expr.strip(): > expr = 'nothing' > super(ZopePathExpr, self).__init__(name, expr, engine, > - boboAwareZopeTraverse) > + self._TRAVERSER) > > # override this to support different call metrics (see bottom of > # method) and Zope 2's traversal exceptions (ZopeUndefs instead of > @@ -150,6 +172,9 @@ > return 1 > return 0 > > +class TrustedZopePathExpr(ZopePathExpr): > + _TRAVERSER = staticmethod(trustedBoboAwareZopeTraverse) > + > class SafeMapping(MultiMapping): > """Mapping with security declarations and limited method exposure. > > @@ -335,11 +360,11 @@ > return False > return ob1 == ob2 > > -def createZopeEngine(): > +def createZopeEngine(zpe=ZopePathExpr): > e = ZopeEngine() > e.iteratorFactory = PathIterator > - for pt in ZopePathExpr._default_type_names: > - e.registerType(pt, ZopePathExpr) > + for pt in zpe._default_type_names: > + e.registerType(pt, zpe) > e.registerType('string', StringExpr) > e.registerType('python', ZRPythonExpr.PythonExpr) > e.registerType('not', NotExpr) > @@ -352,7 +377,7 @@ > def createTrustedZopeEngine(): > # same as createZopeEngine, but use non-restricted Python > # expression evaluator > - e = createZopeEngine() > + e = createZopeEngine(TrustedZopePathExpr) > e.types['python'] = PythonExpr > return e > > From tseaver at palladion.com Mon May 7 16:29:12 2007 From: tseaver at palladion.com (Tres Seaver) Date: Mon, 07 May 2007 10:29:12 -0400 Subject: [z3-five] Templates in views and path expressions In-Reply-To: References: <463E84A4.1010802@palladion.com> Message-ID: <463F37B8.2060900@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: >>> - ViewPageTemplateFile's in a browser view are doing restricted, >>> rather than unrestricted traversals >> This is becuase >> 'Products.PageTemplates.Expression.createTrustedZopeEngine' only trusts >> 'python:' expressions; path traversal is still governed by >> 'boboAwareZopeTraverse', which uses 'restrictedTraverse'. > > That's bad, isn't it? > >>> - The directive doesn't seem to work properly on simple >>> properties >> Your context object somehow has no acquisition wrapper, and therefore >> cannot be verified by Zope's acquisition-based security policy. > > Strange; it derives from CMF's PortalFolder (and a few other things), so > it should be acquisition-aware, and I'm invoking the view via normal > traversal. > > What is telling you that there's no aq wrapper, specifically? The check for 'aq_inContextOf' is failing; that method is defined in C for acquisition wrappers. Could you be running into a case where the context is actually tuple-ified to prevent wrapping it in the view? I think that is an AT thing, but don't recall for sure. >>> Are these bugs? Are my expectations unreasonable? What are the >>> consequences of not having a directive setting permissions on >>> the content type? >> Applications which don't expose their objects to TTW-modifiable code can >> safely leave those declarations out; in fact, all the Five-based apps I >> have worked on do this, as they don't permit "skinning" or >> "customerization". > > Right. I'd still prefer to have it in, though. :) > > I'm also uear what the effect of base classes (e.g. PortalFolder) > doing their own ClassSecrityInfo is on my own derived type, if my > derived type uses neither ClassSecurityInfo directly, nor a > ZCML statement. > >> We had a similar exchange about three weeks ago on the subject, 'ZCML >> security declarations and properties'. I conceded then, through >> failutre to read carefully enough: > > Ah yes, I knew there was a reason I had deja-vu :( > >>> You are correct that the VPTF is trusted code -- my bad. >> As it turns out, it is only "partially trusted." The attached patch >> should make them "really trusted", at least for path expressions; does >> it help? I haven't added any tests, although my 2.10 branch checkout >> does pass all tests with this change. > > It seems to me that being "not fully trusted" is a bug, so I'd be very > happy if this went in! Does the patch fix your problem? I refactored the tests for the Expressions module last night to allow up to write tests for the security semantics of both the trusted and the regular engines, but don't want to go further unless the patch fixes you issue. > I assume this only impacts ViewPageTemplateFiles and not regular > TTW/skin layer Page Templates? RIght: the only client of 'createTrustedZopeEngine' is Products.Five.browser.pagetemplatefile. It is arguable that the normal PageTemplateFile should use this engine as well; for BBB, we'd probably have to expose it as an option to the PTF construtor, and then cahnge the default from untrusted to trusted after a couple of releases. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at 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 iD8DBQFGPze4+gerLs4ltQ4RAoNEAJ9w4RakOTcIJkNkiSiGpZ0KGlm4zQCaAy8Y XX4t96r1Egj/Z6xRplgIvDA= =P9M/ -----END PGP SIGNATURE----- From optilude at gmx.net Mon May 7 16:45:40 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 15:45:40 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463F37B8.2060900@palladion.com> References: <463E84A4.1010802@palladion.com> <463F37B8.2060900@palladion.com> Message-ID: <463F3B94.2010002@gmx.net> Tres Seaver wrote: >>>> - The directive doesn't seem to work properly on simple >>>> properties >>> Your context object somehow has no acquisition wrapper, and therefore >>> cannot be verified by Zope's acquisition-based security policy. >> Strange; it derives from CMF's PortalFolder (and a few other things), so >> it should be acquisition-aware, and I'm invoking the view via normal >> traversal. >> >> What is telling you that there's no aq wrapper, specifically? > > The check for 'aq_inContextOf' is failing; that method is defined in C > for acquisition wrappers. Could you be running into a case where the > context is actually tuple-ified to prevent wrapping it in the view? I > think that is an AT thing, but don't recall for sure. I don't think that has anything to do with AT, and in any case, my product doesn't use Archetypes. I put this in the template: It outputs: [, , , ] The Project at /test/my-workspace is the right context object. So there is an aq chain. Note that the user I'm using here is outside the Plone site root, it's in the PAS acl_users at the root of the Zope site. I think it's the same with a user inside the site's acl_usuers, but I don't have one set up right now to re-test with. Also note that if zope2.View is given to Anonymous (when the object is published) it works in both cases, which I presume is because of the usual short-circuit. > Does the patch fix your problem? I refactored the tests for the > Expressions module last night to allow up to write tests for the > security semantics of both the trusted and the regular engines, but > don't want to go further unless the patch fixes you issue. I'll try it now and reply here. >> I assume this only impacts ViewPageTemplateFiles and not regular >> TTW/skin layer Page Templates? > > RIght: the only client of 'createTrustedZopeEngine' is > Products.Five.browser.pagetemplatefile. It is arguable that the normal > PageTemplateFile should use this engine as well; for BBB, we'd probably > have to expose it as an option to the PTF construtor, and then cahnge > the default from untrusted to trusted after a couple of releases. /me assumes Tres has this under control Martin From optilude at gmx.net Mon May 7 16:56:35 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 15:56:35 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463F37B8.2060900@palladion.com> References: <463E84A4.1010802@palladion.com> <463F37B8.2060900@palladion.com> Message-ID: <463F3E23.5010906@gmx.net> Tres Seaver wrote: > Does the patch fix your problem? I refactored the tests for the > Expressions module last night to allow up to write tests for the > security semantics of both the trusted and the regular engines, but > don't want to go further unless the patch fixes you issue. It seems to work, yes! Thank you! I've tried as a Manager user, and as a user with a local role which has View permission in the context. So, I think that fixes the ViewPageTemplateFiles-are-not-real-trusted problem. I still have a problem with security not being applied properly to attributes, though. I just tried to put an untrusted page template in a skin layer (actually, a temporarily mutilated document_view from Plone), and do on the object. That still gives me the same Unauthorized error as before, even though I thought I'd protected it. For reference, here's the ZCML: and the interface: class IProject(Interface): """A project workspace, where special local roles may apply """ title = schema.TextLine(title=_(u"Title"), description=_(u"Name of the project"), required=True) ... and the class: class Project(Container): implements(IProject, ITTWLockable, INameFromTitle) portal_type = "b-org Project" title = u"" ... and the error: Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module Products.PDBDebugMode.pdbzope.runcall, line 60, in pdb_runcall Module ZPublisher.Publish, line 42, in call_object Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.CMFCore.FSPageTemplate, line 220, in _exec Module Products.CMFCore.FSPageTemplate, line 159, in pt_render Module Products.PageTemplates.PageTemplate, line 89, in pt_render Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 346, in interpret ... Module Products.PageTemplates.Expressions, line 224, in evaluateText Module zope.tales.tales, line 696, in evaluate - URL: file:/Users/optilude/Development/Plone/Code/Build/ploneout/trunk/products/CMFPlone/skins/plone_content/document_view.pt - Line 12, Column 4 - Expression: - Names: {'container': , 'context': , 'default': , 'here': , 'loop': {}, 'nothing': None, 'options': {'args': ()}, 'repeat': , 'request': , 'root': , 'template': , 'traverse_subpath': [], 'user': } Module zope.tales.expressions, line 217, in __call__ Module Products.PageTemplates.Expressions, line 153, in _eval Module zope.tales.expressions, line 124, in _eval Module Products.PageTemplates.Expressions, line 80, in boboAwareZopeTraverse Module OFS.Traversable, line 301, in restrictedTraverse Module OFS.Traversable, line 236, in unrestrictedTraverse - __traceback_info__: ([], 'managers') Module AccessControl.ImplPython, line 563, in validate Module AccessControl.ImplPython, line 454, in validate Module AccessControl.ImplPython, line 808, in raiseVerbose Unauthorized: Your user account is defined outside the context of the object being accessed. Access to 'managers' of (Project at /test/my-workspace) denied. Your user account, admin, exists at /acl_users. Access requires one of the following roles: ['Contributor', 'Editor', 'Manager', 'Owner', 'Reader']. Martin From optilude at gmx.net Mon May 7 16:57:00 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 15:57:00 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463F37B8.2060900@palladion.com> References: <463E84A4.1010802@palladion.com> <463F37B8.2060900@palladion.com> Message-ID: <463F3E3C.5030904@gmx.net> Tres Seaver wrote: >>>> - The directive doesn't seem to work properly on simple >>>> properties >>> Your context object somehow has no acquisition wrapper, and therefore >>> cannot be verified by Zope's acquisition-based security policy. >> Strange; it derives from CMF's PortalFolder (and a few other things), so >> it should be acquisition-aware, and I'm invoking the view via normal >> traversal. >> >> What is telling you that there's no aq wrapper, specifically? > > The check for 'aq_inContextOf' is failing; that method is defined in C > for acquisition wrappers. Could you be running into a case where the > context is actually tuple-ified to prevent wrapping it in the view? I > think that is an AT thing, but don't recall for sure. I don't think that has anything to do with AT, and in any case, my product doesn't use Archetypes. I put this in the template: It outputs: [, , , ] The Project at /test/my-workspace is the right context object. So there is an aq chain. Note that the user I'm using here is outside the Plone site root, it's in the PAS acl_users at the root of the Zope site. I think it's the same with a user inside the site's acl_usuers, but I don't have one set up right now to re-test with. Also note that if zope2.View is given to Anonymous (when the object is published) it works in both cases, which I presume is because of the usual short-circuit. > Does the patch fix your problem? I refactored the tests for the > Expressions module last night to allow up to write tests for the > security semantics of both the trusted and the regular engines, but > don't want to go further unless the patch fixes you issue. I'll try it now and reply here. >> I assume this only impacts ViewPageTemplateFiles and not regular >> TTW/skin layer Page Templates? > > RIght: the only client of 'createTrustedZopeEngine' is > Products.Five.browser.pagetemplatefile. It is arguable that the normal > PageTemplateFile should use this engine as well; for BBB, we'd probably > have to expose it as an option to the PTF construtor, and then cahnge > the default from untrusted to trusted after a couple of releases. /me assumes Tres has this under control Martin From tseaver at palladion.com Mon May 7 17:24:03 2007 From: tseaver at palladion.com (Tres Seaver) Date: Mon, 07 May 2007 11:24:03 -0400 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463F3E3C.5030904@gmx.net> References: <463E84A4.1010802@palladion.com> <463F37B8.2060900@palladion.com> <463F3E3C.5030904@gmx.net> Message-ID: <463F4493.1030300@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: > >>>>> - The directive doesn't seem to work properly on simple >>>>> properties >>>> Your context object somehow has no acquisition wrapper, and therefore >>>> cannot be verified by Zope's acquisition-based security policy. >>> Strange; it derives from CMF's PortalFolder (and a few other things), so >>> it should be acquisition-aware, and I'm invoking the view via normal >>> traversal. >>> >>> What is telling you that there's no aq wrapper, specifically? >> The check for 'aq_inContextOf' is failing; that method is defined in C >> for acquisition wrappers. Could you be running into a case where the >> context is actually tuple-ified to prevent wrapping it in the view? I >> think that is an AT thing, but don't recall for sure. > > I don't think that has anything to do with AT, and in any case, my > product doesn't use Archetypes. > > I put this in the template: > > > > It outputs: > > [, , >, ] Try this: For security purposes, only the "innermost" wrappers (the "true containment") matter. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at 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 iD8DBQFGP0ST+gerLs4ltQ4RAouFAJ4iSu8pUCXstZAfgKTkQGBMoVIBgACfVgNu h5KKwVIVqXOkdcTRVKsqNnY= =DmPx -----END PGP SIGNATURE----- From optilude at gmx.net Mon May 7 17:26:26 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 16:26:26 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463F3E23.5010906@gmx.net> References: <463E84A4.1010802@palladion.com> <463F37B8.2060900@palladion.com> <463F3E23.5010906@gmx.net> Message-ID: Martin Aspeli wrote: > Tres Seaver wrote: > >> Does the patch fix your problem? I refactored the tests for the >> Expressions module last night to allow up to write tests for the >> security semantics of both the trusted and the regular engines, but >> don't want to go further unless the patch fixes you issue. > > It seems to work, yes! Thank you! > > I've tried as a Manager user, and as a user with a local role which has > View permission in the context. > > So, I think that fixes the ViewPageTemplateFiles-are-not-real-trusted > problem. ... and doesn't break security on untrusted code, either, from what I can see. What scope to we have for getting this fix in, in what time frame? I'm hoping we'll be able to have this in a version which Plone 3.0 can depend on. ;) > I still have a problem with security not being applied properly to > attributes, though. I just tried to put an untrusted page template in a > skin layer (actually, a temporarily mutilated document_view from Plone), > and do I've just tried a few more things, all from untrusted code: - Set self.title as an instance variable in the construct, not in the class --> still gets Unauthorized - Add a method get_title() to the class, with a docstring, returning self.title --> accessible - Add get_title() to the interface which is used in the statement --> accessible, but strange that it was *before* I added an explicit declaration for it - Add a new class variable foo = "foo", with no further security declarations --> accessible (!) - Add a new instance variable self.bar = "bar", with no further security delcarations --> accessible (!) So it seems to me that in general, any attribute which is part of an interface protected in a block, is inaccessible, whilst any method protected by an interface with is handled correctly, and any attribute or method not in an interface (i.e. not given explicit security declarations) is also accessible. Martin > > > on the object. That still gives me the same Unauthorized error as > before, even though I thought I'd protected it. > > For reference, here's the ZCML: > > > permission="zope2.View" > interface=".interfaces.IProject" > /> > permission="cmf.ModifyPortalContent" > set_schema=".interfaces.IProject" > /> > > > and the interface: > > class IProject(Interface): > """A project workspace, where special local roles may apply > """ > > title = schema.TextLine(title=_(u"Title"), > description=_(u"Name of the project"), > required=True) > > ... > > and the class: > > class Project(Container): > implements(IProject, ITTWLockable, INameFromTitle) > portal_type = "b-org Project" > > title = u"" > > ... > > and the error: > > Traceback (innermost last): > Module ZPublisher.Publish, line 119, in publish > Module ZPublisher.mapply, line 88, in mapply > Module Products.PDBDebugMode.pdbzope.runcall, line 60, in pdb_runcall > Module ZPublisher.Publish, line 42, in call_object > Module Shared.DC.Scripts.Bindings, line 313, in __call__ > Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec > Module Products.CMFCore.FSPageTemplate, line 220, in _exec > Module Products.CMFCore.FSPageTemplate, line 159, in pt_render > Module Products.PageTemplates.PageTemplate, line 89, in pt_render > Module zope.pagetemplate.pagetemplate, line 117, in pt_render > Module zope.tal.talinterpreter, line 271, in __call__ > Module zope.tal.talinterpreter, line 346, in interpret > ... > Module Products.PageTemplates.Expressions, line 224, in evaluateText > Module zope.tales.tales, line 696, in evaluate > - URL: > file:/Users/optilude/Development/Plone/Code/Build/ploneout/trunk/products/CMFPlone/skins/plone_content/document_view.pt > - Line 12, Column 4 > - Expression: > - Names: > {'container': , > 'context': , > 'default': , > 'here': , > 'loop': {}, > 'nothing': None, > 'options': {'args': ()}, > 'repeat': at 0x8253558>, > 'request': URL=http://localhost:8080/test/my-workspace/document_view>, > 'root': , > 'template': /test/my-workspace>, > 'traverse_subpath': [], > 'user': } > Module zope.tales.expressions, line 217, in __call__ > Module Products.PageTemplates.Expressions, line 153, in _eval > Module zope.tales.expressions, line 124, in _eval > Module Products.PageTemplates.Expressions, line 80, in > boboAwareZopeTraverse > Module OFS.Traversable, line 301, in restrictedTraverse > Module OFS.Traversable, line 236, in unrestrictedTraverse > - __traceback_info__: ([], 'managers') > Module AccessControl.ImplPython, line 563, in validate > Module AccessControl.ImplPython, line 454, in validate > Module AccessControl.ImplPython, line 808, in raiseVerbose > Unauthorized: Your user account is defined outside the context of the > object being accessed. Access to 'managers' of (Project at > /test/my-workspace) denied. Your user account, admin, exists at > /acl_users. Access requires one of the following roles: ['Contributor', > 'Editor', 'Manager', 'Owner', 'Reader']. > > Martin > From optilude at gmx.net Mon May 7 17:30:34 2007 From: optilude at gmx.net (Martin Aspeli) Date: Mon, 07 May 2007 16:30:34 +0100 Subject: [z3-five] Templates in views and path expressions In-Reply-To: <463F4493.1030300@palladion.com> References: <463E84A4.1010802@palladion.com> <463F37B8.2060900@palladion.com> <463F3E3C.5030904@gmx.net> <463F4493.1030300@palladion.com> Message-ID: Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Aspeli wrote: >> Tres Seaver wrote: >> >>>>>> - The directive doesn't seem to work properly on simple >>>>>> properties >>>>> Your context object somehow has no acquisition wrapper, and therefore >>>>> cannot be verified by Zope's acquisition-based security policy. >>>> Strange; it derives from CMF's PortalFolder (and a few other things), so >>>> it should be acquisition-aware, and I'm invoking the view via normal >>>> traversal. >>>> >>>> What is telling you that there's no aq wrapper, specifically? >>> The check for 'aq_inContextOf' is failing; that method is defined in C >>> for acquisition wrappers. Could you be running into a case where the >>> context is actually tuple-ified to prevent wrapping it in the view? I >>> think that is an AT thing, but don't recall for sure. >> I don't think that has anything to do with AT, and in any case, my >> product doesn't use Archetypes. >> >> I put this in the template: >> >> >> >> It outputs: >> >> [, , > >, ] > > Try this: > > > > For security purposes, only the "innermost" wrappers (the "true > containment") matter. This gives the same result. Bear in mind that I'm only traversing to this object "as normal" - I don't see much scope for it to be wrapped in something else. Martin From sidnei at enfoldsystems.com Tue May 8 21:09:58 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Tue, 8 May 2007 16:09:58 -0300 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: Message-ID: Hi Martijn, did that answer your question? I was expecting for some feedback. On 5/4/07, Sidnei da Silva wrote: > On 5/4/07, Martijn Faassen wrote: > > Hi there, > > > > I can find some discussion from last year between Sidnei and Philipp > > about integrating FiveException into the Zope 2 trunk. Has this happened > > yet? > > Timely question my friend. > > There's a working patch against Zope 2.9, with several tests. Just > waiting for some good soul to come and merge it in ;) > > http://www.zope.org/Collectors/Zope/2315 > > We are using this in production. There's only one issue which I've hit > today, if the exception view fails to render it doesn't get logged, > since in the patch renders the view *after* it logged to the error_log > object. > > -- > Sidnei da Silva > Enfold Systems http://enfoldsystems.com > Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 > -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From faassen at startifact.com Tue May 8 21:14:33 2007 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 8 May 2007 21:14:33 +0200 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: Message-ID: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> Hey, Yes, sorry, it did, I got sidetracked. It's very good news, but it still merging it into Zope 2 trunk, basically. Who would that good soul be? :) Who do we bug? Can we do it ourselves? Regards, Martijn From sidnei at enfoldsystems.com Tue May 8 21:17:27 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Tue, 8 May 2007 16:17:27 -0300 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> Message-ID: On 5/8/07, Martijn Faassen wrote: > Hey, > > Yes, sorry, it did, I got sidetracked. It's very good news, but it > still merging it into Zope 2 trunk, basically. Who would that good > soul be? :) Who do we bug? Can we do it ourselves? I can merge into Zope 2 trunk eventually. No promises though. Maybe Martin can look at it since he tried similar stuff in Plone? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From faassen at startifact.com Tue May 8 21:20:18 2007 From: faassen at startifact.com (Martijn Faassen) Date: Tue, 8 May 2007 21:20:18 +0200 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> Message-ID: <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> Hey, Sounds great if we can get Martin to do it. Martin? :) Regards, Martijn From optilude at gmx.net Wed May 9 00:20:38 2007 From: optilude at gmx.net (Martin Aspeli) Date: Tue, 08 May 2007 23:20:38 +0100 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> Message-ID: Martijn Faassen wrote: > Hey, > > Sounds great if we can get Martin to do it. Martin? :) Don't shoot the messenger. I (a) have no time and (b) didn't do any of this, I just know we're using it and (c) don't have Zope svn access (yet). Andreas Zeidler wrote plone.app.linkintegrity, which uses it. Martin From sidnei at enfoldsystems.com Wed May 9 04:47:14 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Tue, 8 May 2007 23:47:14 -0300 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> Message-ID: Alright, back to you Martijn. :) If you can spark some discussion on the zope-dev list I can eventually follow up and merge into trunk. Sounds reasonable? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From philipp at weitershausen.de Fri May 11 01:34:16 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Fri, 11 May 2007 01:34:16 +0200 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> Message-ID: <4643ABF8.6010902@weitershausen.de> Sidnei da Silva wrote: > Alright, back to you Martijn. :) If you can spark some discussion on > the zope-dev list I can eventually follow up and merge into trunk. > Sounds reasonable? +1 on bringing FiveException to the Zope 2 core. Just note that I've looked at this before and found it's hairy. Very hairy. There's a standard zpublisher_exception_hook that handles exceptions in a very very funky way (and I believe it ends up evaluating standard_error_message after various indirections). FiveException simply replaces that exception handling function by hooking in its own. This function is probably too simple for BBB. The Right Way(tm) would probably to document (read: test!) the current behaviour, refactor it to use Five making sure the old behaviour isn't affected (tests still pass). This might take longer than you expect; depending, of course, on the level of BBB you want to retain. There might loads of useless junk in there that can just be thrown out because nobody uses it or because it's broken. -- http://worldcookery.com -- Professional Zope documentation and training From sidnei at enfoldsystems.com Fri May 11 03:06:47 2007 From: sidnei at enfoldsystems.com (Sidnei da Silva) Date: Thu, 10 May 2007 22:06:47 -0300 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: <4643ABF8.6010902@weitershausen.de> References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> <4643ABF8.6010902@weitershausen.de> Message-ID: On 5/10/07, Philipp von Weitershausen wrote: > FiveException simply replaces that exception handling function by > hooking in its own. This function is probably too simple for BBB. The > Right Way(tm) would probably to document (read: test!) the current > behaviour, refactor it to use Five making sure the old behaviour isn't > affected (tests still pass). > > This might take longer than you expect; depending, of course, on the > level of BBB you want to retain. There might loads of useless junk in > there that can just be thrown out because nobody uses it or because it's > broken. What you propose sounds a lot like my patch. I guess you've missed it: http://www.zope.org/Collectors/Zope/2315 -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From philipp at weitershausen.de Fri May 11 08:31:48 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Fri, 11 May 2007 08:31:48 +0200 Subject: [z3-five] FiveException in Zope 2 trunk? In-Reply-To: References: <8928d4e90705081214r67c90e22n19956bbb6ca0e884@mail.gmail.com> <8928d4e90705081220u2901364br1c81ed5cd2c1fbc1@mail.gmail.com> <4643ABF8.6010902@weitershausen.de> Message-ID: On 11 May 2007, at 03:06 , Sidnei da Silva wrote: > On 5/10/07, Philipp von Weitershausen > wrote: >> FiveException simply replaces that exception handling function by >> hooking in its own. This function is probably too simple for BBB. The >> Right Way(tm) would probably to document (read: test!) the current >> behaviour, refactor it to use Five making sure the old behaviour >> isn't >> affected (tests still pass). >> >> This might take longer than you expect; depending, of course, on the >> level of BBB you want to retain. There might loads of useless junk in >> there that can just be thrown out because nobody uses it or >> because it's >> broken. > > What you propose sounds a lot like my patch. I guess you've missed it: > > http://www.zope.org/Collectors/Zope/2315 Indeed I did. After a first glance the patch looks excellent! From shivayogiks at gmail.com Thu May 31 08:47:09 2007 From: shivayogiks at gmail.com (shivayogi Kumbar) Date: Wed, 30 May 2007 23:47:09 -0700 (PDT) Subject: [z3-five] shivayogi K has sent you a private message Message-ID: <1699619672.1180594013863.JavaMail.www@job05.flixster.com> An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/z3-five/attachments/20070530/8db6178a/attachment.htm From chris at simplistix.co.uk Mon Jun 4 08:45:37 2007 From: chris at simplistix.co.uk (Chris Withers) Date: Mon, 04 Jun 2007 07:45:37 +0100 Subject: [z3-five] debugging "missing" view Message-ID: <4663B511.3060701@simplistix.co.uk> Hi All, I have a "properties" view for user objects which works fine on my dev zope instance. However, when I move the software to my customer's staging instance, the view appears to have vanished and I get an exception that looks a bit like: Module Products.PageTemplates.Expressions, line 127, in _eval - __traceback_info__: user Module Products.PageTemplates.Expressions, line 286, in restrictedTraverse - __traceback_info__: {'path': ['@@properties'], 'TraversalRequestNameStack': []} Module Products.Five.traversable, line 115, in __bobo_traverse__ AttributeError: @@properties How can I debug why this view is not being found on one Zope instance while it is being found in another? (this is Five as shipped with Zope 2.9.something) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From jinty at web.de Mon Jun 4 12:09:41 2007 From: jinty at web.de (Brian Sutherland) Date: Mon, 4 Jun 2007 12:09:41 +0200 Subject: [z3-five] debugging "missing" view In-Reply-To: <4663B511.3060701@simplistix.co.uk> References: <4663B511.3060701@simplistix.co.uk> Message-ID: <20070604100941.GA10702@mobilista.local> On Mon, Jun 04, 2007 at 07:45:37AM +0100, Chris Withers wrote: > Hi All, > > I have a "properties" view for user objects which works fine on my dev > zope instance. However, when I move the software to my customer's > staging instance, the view appears to have vanished and I get an > exception that looks a bit like: > > Module Products.PageTemplates.Expressions, line 127, in _eval > - __traceback_info__: user > Module Products.PageTemplates.Expressions, line 286, in > restrictedTraverse > - __traceback_info__: {'path': ['@@properties'], > 'TraversalRequestNameStack': []} > Module Products.Five.traversable, line 115, in __bobo_traverse__ > AttributeError: @@properties > > How can I debug why this view is not being found on one Zope instance > while it is being found in another? I normally resort to using the python debugger for these things because Five is so good at hiding the real problem. > > (this is Five as shipped with Zope 2.9.something) On these versions I find that it's normally a missing five:traversable statement on some global class, in my case normally OFS.Folder. > > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > > _______________________________________________ > z3-five mailing list > z3-five at codespeak.net > http://codespeak.net/mailman/listinfo/z3-five -- Brian Sutherland From chris at simplistix.co.uk Tue Jun 5 10:39:51 2007 From: chris at simplistix.co.uk (Chris Withers) Date: Tue, 05 Jun 2007 09:39:51 +0100 Subject: [z3-five] debugging "missing" view In-Reply-To: <20070604100941.GA10702@mobilista.local> References: <4663B511.3060701@simplistix.co.uk> <20070604100941.GA10702@mobilista.local> Message-ID: <46652157.1010108@simplistix.co.uk> Brian Sutherland wrote: > On Mon, Jun 04, 2007 at 07:45:37AM +0100, Chris Withers wrote: >> - __traceback_info__: {'path': ['@@properties'], >> 'TraversalRequestNameStack': []} >> Module Products.Five.traversable, line 115, in __bobo_traverse__ >> AttributeError: @@properties >> >> How can I debug why this view is not being found on one Zope instance >> while it is being found in another? > > I normally resort to using the python debugger for these things because > Five is so good at hiding the real problem. Yes, that is kind of sad :-S Do you have any particular recommendations as to where to drop a pdb or two? >> (this is Five as shipped with Zope 2.9.something) > > On these versions I find that it's normally a missing five:traversable > statement on some global class, in my case normally OFS.Folder. Nope, that's in the Product's configure.zcml: cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From derek.richardson at gatech.edu Thu Jun 21 17:46:38 2007 From: derek.richardson at gatech.edu (Derek Richardson) Date: Thu, 21 Jun 2007 11:46:38 -0400 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 Message-ID: In z3, I can call absolute_url on a z3 view in a zpt, like so: view/@@absolute_url Adjusting for z2 vs z3 nomenclature, I should be able to do this in z2.10: string:${view/absolute_url} However, I get a traversal error: 1. .2007-06-21 10:43:14 ERROR Zope.SiteErrorLog http://nohost/plone/Members/test_user_1_/emptyDir/atom.xml 2. Traceback (innermost last): 3. Module ZPublisher.Publish, line 119, in publish 4. Module ZPublisher.mapply, line 88, in mapply 5. Module ZPublisher.Publish, line 42, in call_object 6. Module plone.syndication.browser.feed, line 39, in __call__ 7. Module zope.app.pagetemplate.viewpagetemplatefile, line 83, in __call__ 8. Module zope.app.pagetemplate.viewpagetemplatefile, line 51, in __call__ 9. Module zope.pagetemplate.pagetemplate, line 117, in pt_render 10. Module zope.tal.talinterpreter, line 271, in __call__ 11. Module zope.tal.talinterpreter, line 346, in interpret 12. Module zope.tal.talinterpreter, line 379, in do_startEndTag 13. Module zope.tal.talinterpreter, line 408, in do_startTag 14. Module zope.tal.talinterpreter, line 485, in attrAction_tal 15. Module zope.tales.tales, line 704, in evaluateText 16. Module zope.tales.tales, line 696, in evaluate 17. - URL: /Users/dkr/viceplone/lib/python/plone/syndication/browser/atom-1.0.pt 18. - Line 28, Column 2 19. - Expression: 20. - Names: 21. {'args': (), 22. 'context': , 23. 'default': , 24. 'loop': {}, 25. 'nothing': None, 26. 'options': {}, 27. 'repeat': {}, 28. 'request': , 29. 'template': , 30. 'usage': , 31. 'view': , 32. 'views': } 33. Module Products.CMFPlone.patches.unicodehacks, line 36, in new__call__ 34. Module zope.tales.expressions, line 217, in __call__ 35. Module zope.tales.expressions, line 194, in _eval 36. Module zope.tales.expressions, line 124, in _eval 37. Module zope.app.pagetemplate.engine, line 68, in __call__ 38. Module zope.traversing.adapters, line 164, in traversePathElement 39. - __traceback_info__: (, 'absolute_url') 40. Module zope.traversing.adapters, line 52, in traverse 41. - __traceback_info__: (, 'absolute_url', []) 42. TraversalError: (, 'absolute_url') Thanks, Derek From tim at sitefusion.co.uk Thu Jun 21 21:05:04 2007 From: tim at sitefusion.co.uk (Tim Hicks) Date: Thu, 21 Jun 2007 20:05:04 +0100 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 In-Reply-To: References: Message-ID: <467ACBE0.8000309@sitefusion.co.uk> Derek Richardson wrote: > In z3, I can call absolute_url on a z3 view in a zpt, like so: > > view/@@absolute_url > > Adjusting for z2 vs z3 nomenclature, I should be able to do this in z2.10: > > string:${view/absolute_url} > > However, I get a traversal error: Does your view have an 'absolute_url' method? Tim From d.w.morriss at gmail.com Thu Jun 21 21:39:32 2007 From: d.w.morriss at gmail.com (whit) Date: Thu, 21 Jun 2007 14:39:32 -0500 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 In-Reply-To: <467ACBE0.8000309@sitefusion.co.uk> References: <467ACBE0.8000309@sitefusion.co.uk> Message-ID: <467AD3F4.5090709@gmail.com> Tim Hicks wrote: > Derek Richardson wrote: >> In z3, I can call absolute_url on a z3 view in a zpt, like so: >> >> view/@@absolute_url >> >> Adjusting for z2 vs z3 nomenclature, I should be able to do this in z2.10: >> >> string:${view/absolute_url} >> >> However, I get a traversal error: > > Does your view have an 'absolute_url' method? > > Tim something like:: @property def absolute_url(self): return "%s/%s" %(self.context.absolute_url(), view.__name__) view/@@absolute_url would be asking for a view on a view. I don't *think* this would even work for generic views in straight z3. -w -- ------ d. whit morriss ------ - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 From derek.richardson at gatech.edu Thu Jun 21 21:17:20 2007 From: derek.richardson at gatech.edu (Derek Richardson) Date: Thu, 21 Jun 2007 15:17:20 -0400 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 In-Reply-To: <467ACBE0.8000309@sitefusion.co.uk> References: <467ACBE0.8000309@sitefusion.co.uk> Message-ID: <467ACEC0.7020202@gatech.edu> It must not, but that is provided automatically in z3.3, it seems, but not by Five. Did you see the magic: Products.Five.metaclass.Atom_1_0_FeedView Atom_1_0_FeedView is my class, but the Products.Five.metaclass is, from my perspective, deep voodoo. My assumption was simply that it should work in 2.10 like it does in 3.3. I can add a absolute_url function, but that kinda defeats the purpose.... (BTW, Tim, sorry for the dup msg - z3-five rejected my first post). Derek Tim Hicks wrote: > Derek Richardson wrote: >> In z3, I can call absolute_url on a z3 view in a zpt, like so: >> >> view/@@absolute_url >> >> Adjusting for z2 vs z3 nomenclature, I should be able to do this in z2.10: >> >> string:${view/absolute_url} >> >> However, I get a traversal error: > > Does your view have an 'absolute_url' method? > > Tim From philipp at weitershausen.de Sun Jun 24 10:30:44 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Sun, 24 Jun 2007 10:30:44 +0200 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 In-Reply-To: <467AD3F4.5090709@gmail.com> References: <467ACBE0.8000309@sitefusion.co.uk> <467AD3F4.5090709@gmail.com> Message-ID: <467E2BB4.3040307@weitershausen.de> whit wrote: > view/@@absolute_url would be asking for a view on a view. I don't > *think* this would even work for generic views in straight z3. Sure it does. A view is just any other object in the object hierarchy (it happens to be found differnetly than persistent objects, but that's a detail). -- http://worldcookery.com -- Professional Zope documentation and training From philipp at weitershausen.de Sun Jun 24 10:36:29 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Sun, 24 Jun 2007 10:36:29 +0200 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 In-Reply-To: References: Message-ID: <467E2D0D.9090008@weitershausen.de> Derek Richardson wrote: > In z3, I can call absolute_url on a z3 view in a zpt, like so: > > view/@@absolute_url The same should work in Zope 2, *if* you have an appropriate "absolute_url" view reqistered for BrowserViews. Unfortunately, the current implementation in Products.Five.browser.absoluteurl kinda depends on the absolute_url() method being there (see below for that). It shouldn't be registered for *, really, but for something like OFS.interfaces.ITraversable (or whichever interface in Zope 2 defines absolute_url). > Adjusting for z2 vs z3 nomenclature, I should be able to do this in z2.10: > > string:${view/absolute_url} This is not just a change in nomenclature, it's actually doing something very different. The @@ forces view lookup, whereas here you're calling a method. Normally this used to be ok in Zope 2 because all objects are pretty much required to have a loadfull of methods, one of which is absolute_url (hence we ended up in mixin class hell). Five browser views simply don't have that method. -- http://worldcookery.com -- Professional Zope documentation and training From philipp at weitershausen.de Tue Jun 26 01:03:46 2007 From: philipp at weitershausen.de (Philipp von Weitershausen) Date: Tue, 26 Jun 2007 01:03:46 +0200 Subject: [z3-five] Can't call absolute_url on a z3 view in z2.10 In-Reply-To: <467FD4FF.80104@openplans.org> References: <467ACBE0.8000309@sitefusion.co.uk> <467AD3F4.5090709@gmail.com> <467E2BB4.3040307@weitershausen.de> <467FD4FF.80104@openplans.org> Message-ID: <9EF83CD5-60A1-48E5-AE69-97C3C100E657@weitershausen.de> On 25 Jun 2007, at 16:45 , whit wrote: > Philipp von Weitershausen wrote: >> whit wrote: >>> view/@@absolute_url would be asking for a view on a view. I >>> don't *think* this would even work for generic views in straight z3. >> >> Sure it does. A view is just any other object in the object >> hierarchy (it happens to be found differnetly than persistent >> objects, but that's a detail). >> >> > unlike the zope2 publisher, I haven't pdbed through the zope3 > publisher a thousand time, so I haven't seen exactly *why* this > works. Is absolute_url a view on a view in zope3? absolute_url is a view on *, which means *any* object and that includes views. Also, resolving a TALES expression like obj/@@some_view/ @@absolute_url has nothing to do with the publisher. Because you're not publishing a URL. You're just resolving a path that maybe looks a bit like a relative url, but it's just a path in your object graph. (Try going to http://localhost:8080/@@absolute_url in Zope 3. It won't work, and that's the way it should be, unlike in Zope 2). Note that Zope 3's absolute_url view, much like Five's absolute_url view, is lying a bit. It really expects a __parent__ attribute for walking up the hierarchy to compute the URL (browser views have __parent__, that's why it works), so it should really be registered for ILocation (which is the API that guarantees __parent__). Likewise, Five's absolute_url view expects an aq_parent, so it should really be registered for one of those interfaces from Acquisition.interfaces.