Products.Five: browser.view directive ignores access control directives.

[Martijn Pieters]

The following zcml should protect the listed page with the zope2.Private permission (e.g. not viewable at all from the web):

  <configure
      xmlns="http://namespaces.zope.org/zope"
      xmlns:browser="http://namespaces.zope.org/browser">
  <browser:view
      name="foo"
      for="*"
      class=".foo.FooView
      permission="zope2.Private"
      >
    <browser:page name="bar attribute="bar" />
  </browser:view>
  </configure>

However, the @@foo/bar page is perfectly accessible, because the Products.Five.browser.metaconfigure.view configuration handler effectively ignores the permission.

There is in fact no way to protect a view (and the associated pages) from anonymous access with ZCML. The allowed_interface and allowed_attributes are similarly ignored.

Workaround: use old-style security=ClassSecurityInfo() markers on the view class itself. This only works with attribute-based pages.

[Hanno Schlichting (hannosch)]

Could you try to use a different permission, like "zope2.ViewManagementScreens" or "zope2.ManageUsers"?

I don't see any other mention of "zope2.Private" except in the permissions.zcml file in Five. It doesn't look like it's a valid permission in the AccessControl sense.

In site.zcml we have:

<meta:redefinePermission from="zope2.Public" to="zope.Public" />

which seems to take care of the public counterpart, but there's no such entry for the private one. It looks to me like the private permission is a decoy.

[Martijn Pieters (mjpieters)]

I used zope2.Private as an example. My real-world code used another permission altogether (custom in this case). But if you look at the code in question you can see that the permission is never used.

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Pieters wrote:
> I used zope2.Private as an example. My real-world code used another
> permission altogether (custom in this case). But if you look at the code
> in question you can see that the permission is never used.

Can you please provide a functinoal test which demonstrates the failure
with a "stock" permission?

  status incomplete

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvoSfcACgkQ+gerLs4ltQ7kewCg3Ki1JQ7qw/O6hqpccFlNdu7b
zU4AoNspGHpontePbrodFwETFSoSYY2i
=4NCN
-----END PGP SIGNATURE-----

[Hanno Schlichting (hannosch)]

Triggered by a mailing list post on cmf-dev I looked over the code myself. The view directive indeed ignores the permission. The other directives use a "five:protectClass" directive to do something with it.

[Charlie_X (charlie)]

I can confirm that this also applies to browser:page configuration.

Products.Five/browser/metaconfigure.py the culprit right? Views should behave like the Products.CMFDefault/formlib/form/ContentAddFormView which uses an explicit privacy declaration.

[Charlie_X (charlie)]

It looks like there is simply no test of a restricted view such as 'eagle.html' from a non-authenticated user.

[Martijn Pieters (mjpieters)]

Thanks for looking it over and confirming this Hanno, I kept forgetting to create a functional test for this.

[Martin Aspeli (optilude)]

Ok... I think this is fixed in 2.12 branch r114488 and merged to trunk in r114490.