Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
BrowserViews implement IPublishTraverse in Zope 4 which breaks allowed_attributes and allowed_interface #397
In Zope 4 a
<browser:page name="foo" for="*" class=".dummy.Foo" permission="zope2.View" allowed_attributes="bar" />
from Products.Five import BrowserView class Foo(BrowserView): def __call__(self): return 'foo' def bar(self): """bar""" return 'foobar'
In Zope 2 (Plone 5.1) http://0.0.0.0:8080/Plone/foo/bar returned
The relavant code is in
if IPublishTraverse.providedBy(ob): ob2 = ob.publishTraverse(self, name) else: adapter = queryMultiAdapter((ob, self), IPublishTraverse) if adapter is None: # Zope2 doesn't set up its own adapters in a lot of cases # so we will just use a default adapter. adapter = DefaultPublishTraverse(ob, self) ob2 = adapter.publishTraverse(self, name)
In Zope 4
And like this after it:
@jaroel and me were trying to figure out a solution but we require help.
This issue is a replacement for the original ticket plone/Products.CMFPlone#2624 which I moved to Zope since it is not directly related to Plone.
This was referenced
Nov 11, 2018
I found out that Yuppie was the author of the changes in
The changenotes make me guess these might be responsible for the issue:
First of all, I don't know much about the internals here, but bear with me.
I've tried to look at Yuppie's checkins from that period and it's clear that there's so much changed it's not going to be possible to unravel that and make sense of it.
I'm looking at that mixed in class
IMHO implementing a
referenced this issue
May 10, 2019
I have found code in
In PR #610 I have done the first step and added a failing test. For comparison, it exercises the code path that would have been taken if the view did not implement
Now we should think of a sensible
Another option would be to have
Note: I don't think anything in Plone world is relying on the
I also found another feature in Plone that is broken because of this: Unlocking locked objects. That's almost as easy to test as enabling ical-upload to a folder and much more important.
I've had a look a this today, following a request from @pbauer and I've got to say, I'm a bit confused.
Firstly, it looks like the
What's confusing me is why permissions are a problem at all. I'm sure I'm just misunderstanding, but the following appears to work for me:
(With an equivalent line that adds the whitelist in Products.Five, of course)
That causes the ical view to work for me TTW (albeit with a CSRF error that I assume is unrelated) and causes @pbauer's test in plone.app.event to pass.
It seems to me that if the
I'm sure that there are other related approaches, like mutating
Can someone tell me what I've missed? In the unlikely case that this is useful code, I've got some tests I can share too.
Matthew Wilkes wrote at 2019-5-26 14:19 -0700:
... What's confusing me is why permissions are a problem at all. I'm sure I'm just misunderstanding, but the following appears to work for me:
The `publishTravere` methods are relevant for traversal. Authentication happens only after the traversal; therefore, during traversal, the correct permissions are not yet set up. The "normal" `ZPublisher` traversal works around this problem by remembering which roles are required for the traversal and delaying the check until after authentication has taken place. Maybe, something like this is necessary also for `allowed_attributes` and `allowed_interfaces`.
@d-maurer The correct permissions don't need to be set up for traversal, though. The
Matthew Wilkes wrote at 2019-5-27 11:38 -0700:
@d-maurer The correct permissions don't need to be set up for traversal, though. The `allow_attributes` parameter to the metadirective ensures that the permissions are set appropriately for the attributes, it's not the job of the traverser to implement permission checks so it shouldn't matter that the user isn't set up yet.
The argument has been: Currently, you cannot - during traversal - access attributes not granted to "Anoynmous". This is because authentication happens only after traversal. I am not sure whether this is the real problem discussed in this issue. If it is, then there are not many options: * what the publisher currently does for "normal" attribute access: grant the access tentatively and delay the permission check until after authentication has happened * move the authentication forward in the traversal process -- this will be difficult due to the semantics and flexibility of Zope's authentication subframework (where the object responsible for authentication can only be determined late in the traversal process). Of course, this applies only to attributes really accessed *during* traversal - not to accesses that are only prepared by the traversal but occur after the authentication.