grok.require directive should use a default value of 'zope.View'

[Christian Theune]

Currently the grok.require directive doesn't specify a default and causes "check_or_default_permission" to fall back to zope.Public.

Two unfortunate issues:

- The default generated site.zcml says to remove zope.View from the anybody principal in order to disable public access. This won't work, as zope.Public is always accessible.
- zope.Public is not a permission and can't be taken away at all.

I think, we should make zope.View the default permission set by the grok.require directive if nothing is specified.

[Reinout van Rees (reinout)]

jw says this is great one for the EP sprint

[Reinout van Rees (reinout)]

Apparent agreement on the mailinglist that is is a good change, so it's a confirmed issue now.

[Reinout van Rees (reinout)]

jw says high prio 1.0 :-)

[trollfot (trollfot)]

This issue is "fixed".

The latest 'grokcore.security' package was depending on 'zope.security' 3.6.2 which is not the version officialy supported by "Grok". This has been reverted and the package is now back using 'zope.app.security'. In order to avoid depending on the 'zope.View' permission, we added a new permission in the 'grokcore.security' packaged called 'grok.View'. This permission is now the fallback value.

In the same time, we had to upgrade grokproject in order to get a consistent security policy by adding a zcml snippet (site.zcml) assigning the grok.View to zope.Anybody.

'grokcore.security' has been released in his 1.1 version on pypi

'grokproject' depends on the versions.cfg present in 'Grok' so we need to wait for a release of 'Grok' to be able to release 'grokproject'.

[Reinout van Rees (reinout)]

All code is committed, including test changes in grokcore.* packages to compensate for this change.

[Jan Wijbrand Kolman (janwijbrand)]

In the process of releasing 1.0b, we decided that it is better after all to use the more "standard" zope.View permission, not the grok.View permission.