Edit-page fails if anonymous user doesn't have 'view' permission

[MichaelRedmann]

If you transfer the permission 'view' from 'Anonymous' to 'Authenticated' eg in the workflow-state 'published' of simple_publication_workflow, you can't edit an associated object via the edit-page.

You can still edit it with inline-edit.

Steps to reproduce:

• fresh plone3-final install
  
• transfer 'view'-permission from 'Anonymous' to 'Authenticated' at simple_publication_workflow, state 'published'
  
• Update security settings
  
• Login to Plone as admin
  
• try to edit the start-page via edit-page -> Insufficient Privileges
  
• try to edit the start-page via inline edit -> works as expected

Here is the traceback with 'verbose security on':

Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Products.CMFFormController.FSControllerPageTemplate, line 90, in __call__
  Module Products.CMFFormController.BaseControllerPageTemplate, line 26, in _call
  Module Products.CMFFormController.FormController, line 384, in validate
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Products.CMFFormController.FSControllerValidator, line 58, in __call__
  Module Products.CMFFormController.Script, line 145, in __call__
  Module Products.CMFCore.FSPythonScript, line 140, in __call__
  Module Shared.DC.Scripts.Bindings, line 313, in __call__
  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.CMFCore.FSPythonScript, line 196, in _exec
  Module None, line 24, in validate_atct
   - <FSControllerValidator at /Plone/validate_atct used for /Plone/front-page>
   - Line 24
  Module Products.Archetypes.BaseObject, line 513, in validate
  Module Products.Archetypes.Schema, line 602, in validate
  Module Products.Archetypes.Field, line 324, in validate
  Module Products.Archetypes.Field, line 337, in validate_validators
  Module Products.validation.chain, line 142, in __call__
  Module Products.validation.validators.IdValidator, line 24, in __call__
  Module Shared.DC.Scripts.Bindings, line 313, in __call__
  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.PythonScripts.PythonScript, line 327, in _exec
  Module None, line 86, in check_id
   - <CustomizedPythonScript at /Plone/check_id used for /Plone/front-page>
   - Line 86
  Module AccessControl.ImplPython, line 686, in guarded_getattr
  Module Shared.DC.Scripts.Bindings, line 184, in __getattr__
  Module AccessControl.ImplPython, line 563, in validate
  Module AccessControl.ImplPython, line 430, in validate
  Module AccessControl.ImplPython, line 808, in raiseVerbose
Unauthorized: The proxy roles set on the executing script do not allow access. Access to 'getId' of (ATDocument at /Plone/front-page) denied. Access requires one of the following roles: ['Authenticated']. The executing script is (CustomizedPythonScript at /Plone/check_id used for /Plone/front-page), with proxy roles: ['Manager'].

[sirgarr]

A fix: in CMFPlone/skins/plone_scripts/check_id.py.metadata, change proxy = Manager to proxy = Authenticated, Manager

[limi]

This is important to fix for 3.0.1 — Alec, can you take a look at this? I believe this changed because we made the check_id script be a manager so it wouldn't fail. Seems like it needs to proxy the Authenticated role too (or it shouldn't be checking for Authenticated in the first place, I'm not sure of the details here).

[sirgarr]

getId checks for the "View" permission. The workflow right now doesn't assign the Manager the View permission, so the check_id's proxy role Manager isn't powerful enough to let check_id View the obj and access obj.check_id

The problem with changing proxy roles to proxy = Authenticated, Manager is that the same thing will appear when a workflow is changed to make View accessible to, say, Editor or Owner or Contributor but not Authenticated or Manager. Nor will changing proxy roles to proxy = Authenticated, Reader, Editor, Contributor, Owner, Manager work, because then if a new local role is defined, I think it is impossible to modify the proxy roles of check_id through the web. (If you customize check_id and add proxy roles, it will intersect the proxy roles with the roles of the owner of the object check_id.)

Nor does it seem to work to both grant View permission to the Manager for all workflows, and to change proxy = Authenticated, Manager -- because this still would require that developers make sure that every workflow state has permission View granted to either Anonymous, Authenticated, or Manager.

Is there a reason check_id is in a portal skin, rather than just in trusted code in the filesystem? If we never want check_id to fail calling getId, that would be the way to do it!

Peace, George

[limi]

Replying to sirgarr:

Is there a reason check_id is in a portal skin, rather than just in trusted code in the filesystem? If we never want check_id to fail calling getId, that would be the way to do it!

No, there is no real reason, just historical ones. If this would fix the bug, I think it's a good idea. Care to give it a shot and check it in or attach a patch?

[alecm]

Conversion to trusted code will happen eventually, but it's probably too deep a change for a bugfix release. For now the proxy roles have been extended to include Authenticated, Owner, and Anonymous which should cover all but the most extremely privacy conscious workflows (e.g. those where Managers really shouldn't be viewing/editing some content).

The default workflows should also probably be adjusted to grant permission explicitly to those roles which should have them, rather than relying on the peculiar magic of the Anonymous and Authenticated roles, but another ticket should be filed for this.