Five: pagetemplate want a context with Zope 2 security context

Bug #176566 reported by Sylvain Viollon
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Zope 2
Invalid
Low
Unassigned

Bug Description

If you have a class, non-persitant, generated on the fly, with a browser view on it, using a pagetemplate and a view class, you can't access to the view class from the template, you have a '<UnauthorizedBinding context>' instead. (The template alone, or view class work well).

This happens because the view class is acquired from the context, with a Zope 2 security check. In 'Products.Five.browser.pagetemplatefile' view is acquired using 'self._getContext()' (defined in 'Shared.DC.Scripts.Bindings', which search in the aquisition parent context, checking the security. Since our object have been generated, is not persistent, or comes from a content type, it don't have any Zope security items on it.

All of all, the security here is enforced in the 'configure.zcml' file, when the page is declared. So I don't think we need this check, which prevent this case to work. I think it's always the same case, in Five/Zope 3 techniques, if you have the right to see the template (so the context), you have the right to see the view class, which is merly accessor to context (with logic in it).

You can correct this problem, by adding a method to 'Products.Five.browser.pagetemplatefile.ZopeTwoPageTemplateFile':

   def _getContext(self):
      while 1:
         self = self.aq_parent
         if not getattr(self, '_is_wrapperish', None):
            return self

Got this problem with Zope 2.9 (Five 1.4.4) and Zope 2.10 (default shipped Five version).

Revision history for this message
Andreas Jung (ajung) wrote :

Could you please provide a unittest for the patch?

Revision history for this message
lizz-y (tanglisha+launchpad-net) wrote :

I'm not sure how to test for this, but the bug came up for me.

I tried the patch, and it worked very well.

Revision history for this message
Andreas Jung (ajung) wrote :

Hi Philipp,

do you think that this patch is acceptable in this form?

Changed in zope2:
assignee: nobody → philipp-weitershausen
Revision history for this message
Philipp von Weitershausen (philikon) wrote : Re: [Bug 176566] Re: Five: pagetemplate want a context with Zope 2 security context

On 8 Jan 2008, at 18:29 , Andreas Jung wrote:
> do you think that this patch is acceptable in this form?

No, because it doesn't have a test.

Revision history for this message
Sylvain Viollon (thefunny) wrote :

I will make a test (to show the problem) and to check the patch.

Revision history for this message
jjmojojjmojo (joshjohnson-cpc) wrote :

I can't comment on the validity of the patch (I haven't dug into _why_ it works), but it does work, and as such I've created a unit test for it in the hopes that the patch will be accepted (I was writing a test anyway so I could track if it ever got fixed).

The attached test illustrates the error, does a monkey patch, and then illustrates it's success. I run it through a PloneTestCase-based functional test, but I don't see why it wouldn't work in a basic zope test case with a little tweaking. You'd just need to pass some sort of context object to TestRequest instead of self.portal.

JJ

Revision history for this message
kevin7kal (plone-kevinkal) wrote :

is the unit test acceptable to warrant a patch? I only have the issue when making views that use the plone main_template macros, but not the default zope2 macros.

I am working around it using this code.

from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile

class myVPTF(ViewPageTemplateFile):
    ''' patch view page template file '''
    def _getContext(self):
         while 1:
             self = self.aq_parent
             if not getattr(self, '_is_wrapperish', None):
                  return self

class MyPage(BrowserPage):
    ''' a page '''
    __call__ = myVPTF('my_template.pt')

Revision history for this message
Lennart Regebro (regebro-gmail) wrote :

I'm a bit confused about the bug description. The problem seem sto be that the object in question doesn't have an acquisition context, because it is non-persistent. But non-persistent objects can have an acquisition context. And indeed, if you have traversed to them, they should have. And if it does, then the security should work as usual.

Revision history for this message
Hanno Schlichting (hannosch) wrote :

From what I understand here the "non-persistent" object in the original description seems to be lacking the Acquisition base classes. It sounds to me like someone is trying to use Acquisition-less objects inside Zope2, which simply doesn't work. On Zope2 SVN trunk the options exists to constructs __parent__ pointers instead, but the bug report makes it clear that an older version of Five's ViewPageTemplateFile has been used (self._getContext isn't used anymore on Zope trunk).

Calling a BrowserView directly without traversing to it, does not set up an Acquisition chain. The "unittest" in question fails for good reasons here. I'd say this is an invalid report. Sorry, Zope2 does have its own requirements which are different from Zope3.

Revision history for this message
kevin7kal (plone-kevinkal) wrote :

if calling the view on say just a zope2 folder and if my_template.pt is

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
      xmlns:tal="http://xml.zope.org/namespaces/tal"
      xmlns:metal="http://xml.zope.org/namespaces/metal"
      xmlns:i18n="http://xml.zope.org/namespaces/i18n"
      lang="en"
      metal:use-macro="context/@@standard_macros/page"
      i18n:domain="plone">
<body>
<div metal:fill-slot="body" >
        <h1>HI </h1>
</div>
</body>
</html>

there's no error, but if the view within plone and the above template is used without the _getContext page template, the result is a traceback.

  Module zope.tales.tales, line 696, in evaluate
   - URL: file:/home/kalupson/XAM_SANDBOX/WebLionXAM2/parts/plone/CMFPlone/skins/plone_templates/main_template.pt
   - Line 30, Column 4
   - Expression: <StringExpr u'plone.htmlhead'>
   - Names:
      {'container': <PloneSite at /XAM_Site>,
       'context': <PloneSite at /XAM_Site>,
       'default': <object object at 0xb7d97528>,
       'here': <PloneSite at /XAM_Site>,
       'loop': {},
       'nothing': None,
       'options': {'args': ()},
       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xd62a9ec>,
       'request': <HTTPRequest, URL=http://localhost:8080/XAM_Site/xam_store>,
       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xd62a8ec>,
       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,
       'view': <UnauthorizedBinding: context>,
       'views': <zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object at 0xd62a94c>}
  Module Products.Five.browser.providerexpression, line 25, in __call__
ContentProviderLookupError: plone.htmlhead

a similar issue is talked about here, which lead me to this bug report.

http://athenageek.wordpress.com/2008/01/08/contentproviderlookuperror-plonehtmlhead/

This way of making views in plone used to "work" for me and now does not. I am not sure if this is a bug in Zope2PageTemplateFile, a bug in ViewPageTemplateFile, a bug in the plone (3.1) implementation of viewlets regarding the main_template or if there is no bug but something I should be doing differently. Hopefully I'll find out soon :-)

Revision history for this message
Lennart Regebro (regebro-gmail) wrote :

I suspect your usage of this patch hides the real error. I think you should bring it up on the plone-users mailing list.

Revision history for this message
Hanno Schlichting (hannosch) wrote :

Can someone provide a full reproducible example of how they are getting the error? It looks to me like the problem lies in the way people are either calling the view or the context object they are calling it on. Both are not covered in any of the descriptions.

Revision history for this message
kevin7kal (plone-kevinkal) wrote :

I've made available an egg for testing this issue.
https://weblion.psu.edu/svn/weblion/users/kjk137/wl.ktest
https://weblion.psu.edu/trac/weblion/browser/users/kjk137/wl.ktest

I've tested with

    * Plone 3.1.7
    * CMF 2.1.1
    * Zope (Zope 2.10.6-final, python 2.4.5, linux2)
    * Python 2.4.5 (#2, Jul 31 2008, 18:51:48) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
    * PIL 1.1.6

to reproduce the issue:

    * install the egg with easy_install and include the package wl.ktest or buildout/eggtractor , etc
    * also be sure that plone 3.1.7 is installed
    * restart zope
    * if you do not have a plone site, create a plone site
    * any item providing OFS.interfaces.IFolder will have 2 forms available pform and pform2
    * use pform at the zope root
    * use pform at the root of your plone site and then check your error log
    * repeat with pform2 and see that it succeeds in both cases

I hope this is enough info, please let me know if in fact I should report this to the plone users list as an issue for further trouble shooting.

Revision history for this message
Sylvain Viollon (thefunny) wrote :

Hello,

  To update the description of the bug, my context class did inherit from Acquisition.Explicit, Base and Traversable (Zope 2.9), and got correctly wrapped with __of__.

   Maybe I should have used Implicit. But the fact is that the object was created by an adapter, as a computed solution of a problem and after displayed (object/@@view in a template). You could display without any error using a view class, or a template, but not a template and a view class (with some helpers method for the template) in the same time. The configuration was registered with ZCML.

Revision history for this message
Reinout van Rees (reinout) wrote :

I had the same error message with Products.Collage. I had to debug someone's implementation of a collage viewlet that couldn't find a perfectly findable provider. I got the <UnauthorizedBinding context>. Weird.

In the end, I only had to change the zcml security declaration on the viewlet from "zope2.View" to "zope.public". So this matches a bit with the "zope2 security check" comment of the original bug report.

Hope this helps someone :-)

Revision history for this message
Rocky Burt (rocky-burt) wrote :
Download full text (4.1 KiB)

With Zope 2.10, the bug seems to evolved a bit. Either that or this is new altogether. But it ends up being a problem whenever applying a configure.zcml based security declaration beyond zope.Public to a view based on formlib that uses a template using ViewPageTemplateFile from Five. The traceback is as follows (and the above-mentioned _getContext patch does not fix/change this issue):

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 zope.formlib.form, line 770, in __call__
  Module zope.formlib.form, line 764, in render
  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.CacheSetup.patch_cmf, line 74, in PT_pt_render
  Module Products.CacheSetup.patch_utils, line 9, in call_pattern
  Module Products.PageTemplates.PageTemplate, line 98, 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 zope.tal.talinterpreter, line 891, in do_useMacro
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 891, in do_useMacro
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 536, in do_optTag_tal
  Module zope.tal.talinterpreter, line 521, in do_optTag
  Module zope.tal.talinterpreter, line 516, in no_tag
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 408, in do_startTag
  Module zope.tal.talinterpreter, line 485, in attrAction_tal
  Module Products.PageTemplates.Expressions, line 228, in evaluateText
  Module zope.tales.tales, line 696, in evaluate
   - URL: file:/home/rocky/dev/downloads/python-eggs/Plone-3.2.2-py2.4.egg/Products/CMFPlone/skins/plone_templates/main_template.pt
   - Line 73, Column 2
   - Expression: <StringExpr u'${here/getSectionFromURL} template-${template/id}'>
   - Names:
      {'container': <SuperFolder at /intranet/test-folder/ntoplevel>,
       'context': <SuperFolder at /intranet/test-folder/ntoplevel>,
       'default': <object object at 0xb7e4f528>,
       'here': <SuperFolder at /intranet/test-folder/ntoplevel>,
       'loop': {},
       'nothing': None,
       'options': {'args': ()},
       'repeat': <Products.PageTemplates.Expressions.SafeMapping object at 0xee691ac>,
       'request': <HTTPRequest, URL=http://localhost:8080/intranet/test-folder/ntoplevel/search.html>,
       'root': <Application at >,
       'template': <ImplicitAcquirerWrapper object at 0xee59aac>,
       'traverse_subpath': [],
       'user': <PropertiedUser 'admin'>,
       'view': <Produc...

Read more...

Revision history for this message
Hanno Schlichting (hannosch) wrote :

This needs triaging. Maybe the situation changed in Zope 2.12 and all the changes to views and Acquisition.

Changed in zope2:
assignee: Philipp von Weitershausen (philikon) → nobody
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Colin Watson (cjwatson) wrote :

The zope2 project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope2.

Changed in zope2:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.