[Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION

Tres Seaver tseaver at zope.com
Fri Jan 23 17:04:53 EST 2004


Dieter Maurer wrote:
> Brian Lloyd wrote at 2004-1-22 10:11 -0500:
> 
>>>I did check with a fresh 2.6 xx
>>>A DCWorkflow script that was not not called with the version from a few 
>>>hours ago is now called but produces the following traceback
>>>
>>>This happens when the container binding is set to "container" and also 
>>>when it is cleared.
>>
>>...
>>
>>>   - <PythonScript at 
>>>/zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner>
>>>   - Line 1
>>>AttributeError: StateChangeInfo instance has no attribute 
>>>'getPhysicalRoot'
> 
> 
> This problem has nothing to do with the recent security enhancements:
> 
>      "StateChangeInfo" does not have a "getPhysicalRoot" attribute.
>      It never had and it should not have...
> 
> Check your "setTaskOwner" script.
> Almost surely, you do not want to call "getPhysicalRoot" on the
> "state_change" but on the affected object.

I'm afraid this code does have to do with the new security:  the code 
which is failing is actually inside ZopeSecurityPolicy.validate::

     if proxy_roles:
         # Verify that the owner actually can state the proxy role
         # in the context of the accessed item; users in subfolders
         # should not be able to use proxy roles to access items
         # above their subfolder!
         owner = eo.getOwner()
         # Sigh; the default userfolder doesn't return users wrapped
         if owner and not hasattr(owner, 'aq_parent'):
             udb=eo.getOwner(1)[0]
             root=container.getPhysicalRoot()
             udb=root.unrestrictedTraverse(udb)
             owner=owner.__of__(udb)

The script being called is invoked during a workflow transition, which 
calls the script, passing a StateChangeInfo instance;  the new code 
tries to validate access to the SCI and pukes, badly, because the script 
has proxy roles, but the 'container' isn't wrapped.  I *think* that we 
are seeing this issue because the new security code is tougher about 
checking access within the script.

I tried to work around the issue by adding a 'getPhysicalRoot' method to 
SCI, merely delegating to the underlying object;  however, the script in 
my app then blows up on access to 'object' (which I may be able to fix 
as well).

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com




More information about the Zope-Dev mailing list