Port whitelist creation from zope.browserpage

[pbauer]

Together with zopefoundation/zope.browserpage#7 this fixes #397.

All Plone tests are green with that (see plone/buildout.coredev#588)

Open points:

• Implement a pair of tests using allowed_interface.

[icemac]

In #610 @jaroel requested to be able to have a custom IPublishTraverse adapter. IMHO this is not solved by this PR. Is this request still valid?

[icemac]

I ported the tests from branch issue_397 here but the test for accessing the allowed attribute fails. Am I missing a part of the solution?

[MatthewWilkes]

Okay, I've fixed that failing test and cleaned up the implementation a bit. Rather than relying on replacing __call__ I've moved the implementation of browserDefault from the metaconfigure directive into the simple class and added code to handle the changing attribute to avoid having to rebind the function.

I'm waiting for the Plone tests to finish, but I'm hopeful.

[MatthewWilkes]

@jaroel Can you clarify how important a usecase you think the publish traverse adapter is? It's possible to add a publishTraverse method directly to a view, but if we really need to support adapter based things I think we can. We'd probably need to add an adapter lookup in the publishTraverse of the simple class that looks up the adapter on the relevant baseclass.

[jaroel]

@MatthewWilkes , @icemac,
I mainly said that because in Plone+Zope2 a Browserview doesn't implement IPublishTravese, which in turn make the publisher query for an adapter, or use a fallback.
The latter is why the sub path traversal worked in the first place.

I'm unaware of code that uses the IPublishTraverse-as-adapter approach, so the current approach should work just fine by the looks of it.

[icemac]

This PR looks okay to me, I think a test for allowed_interface should be added for completeness. After the explanation of @jaroel I think we could drop the requirement of using a adapter. It could be added later if there is an actual demand.

[icemac]

zopefoundation/zope.browserpage#7 currently fails.

[MatthewWilkes]

@icemac Yep, it does. I've not had a chance to look at this again yet, but my instinct is that the problem is the test, not the code. It's testing that browserDefault is None as a way of identifying a misconfigured view, but I'm not convinced that is legitimate. We could likely add a special case for that, but I'd probably approach it by making the test more closely resemble the traversal/publishing flow.

[pbauer]

I have no real idea if the code is wrong or the test. But in zopefoundation/zope.browserpage@6ab5166 I attempted to adapt the test to show what's actually going wrong with the misconfigured view.

[icemac]

After zopefoundation/zope.browserpage#7 is accepted, merged and released. The do not merge label can be dropped here.