RE: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
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. -- Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
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[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
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.
Traceback (innermost last):
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.CMFCore.FSPythonScript, line 92, in __call__
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 126, in _exec
- __traceback_info__: ({'traverse_subpath': [], 'container':
PloneSite instance at 95efa58, 'context': PloneFolder instance
at 9615280, 'script': FSPythonScript at
/zehnder/zehnder/createObject used for
/zehnder/zehnder/tasklist/Task.2004-01-21.1914/Attachments},
(None, 'File', None), {}, (None, None, None))
Module None, line 12, in createObject
Module Products.CMFCore.PortalFolder, line 362, in invokeFactory
Module Products.CMFCore.TypesTool, line 824, in constructContent
Module Products.CMFCore.TypesTool, line 516, in constructInstance
Module Products.CMFCore.TypesTool, line 420, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 101, in
notifyWorkflowCreated
Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated
Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 311, in _exec
Module None, line 1, in setTaskOwner
- PythonScript at
/zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner
- Line 1
AttributeError: StateChangeInfo instance has no attribute
'getPhysicalRoot'
Robert
It would be helpful if you could go through that in the debugger
and see if you can get any more info - I don't see anything in
this that obviously points to any of the recent security changes.
That's not to say that one of those changes couldn't still be the
cause, but this traceback doesn't point to anything we can look
at :(
Alternatively, if you can make a copy of the failing script and
boil it down to the minimum possible code that demostrates something
that should be working but isn't (and that excludes app-specific or
Plone objects if possible so that we can turn it into a unit test)
I can try to look at it here.
thx,
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: RFC: backward compatibility of ps bindingsRESOLUTION
Brian Lloyd wrote:
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.
Traceback (innermost last):
Module ZPublisher.Publish, line 98, in publish
Module ZPublisher.mapply, line 88, in mapply
Module ZPublisher.Publish, line 39, in call_object
Module Products.CMFCore.FSPythonScript, line 92, in __call__
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.CMFCore.FSPythonScript, line 126, in _exec
- __traceback_info__: ({'traverse_subpath': [], 'container':
PloneSite instance at 95efa58, 'context': PloneFolder instance
at 9615280, 'script': FSPythonScript at
/zehnder/zehnder/createObject used for
/zehnder/zehnder/tasklist/Task.2004-01-21.1914/Attachments},
(None, 'File', None), {}, (None, None, None))
Module None, line 12, in createObject
Module Products.CMFCore.PortalFolder, line 362, in invokeFactory
Module Products.CMFCore.TypesTool, line 824, in constructContent
Module Products.CMFCore.TypesTool, line 516, in constructInstance
Module Products.CMFCore.TypesTool, line 420, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 101, in
notifyWorkflowCreated
Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated
Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition
Module Shared.DC.Scripts.Bindings, line 298, in __call__
Module Shared.DC.Scripts.Bindings, line 329, in _bindAndExec
Module Products.PythonScripts.PythonScript, line 311, in _exec
Module None, line 1, in setTaskOwner
- PythonScript at
/zehnder/zehnder/portal_workflow/ZWorkflow/scripts/setTaskOwner
- Line 1
AttributeError: StateChangeInfo instance has no attribute
'getPhysicalRoot'
Robert
It would be helpful if you could go through that in the debugger
and see if you can get any more info - I don't see anything in
this that obviously points to any of the recent security changes.
That's not to say that one of those changes couldn't still be the
cause, but this traceback doesn't point to anything we can look
at :(
Alternatively, if you can make a copy of the failing script and
boil it down to the minimum possible code that demostrates something
that should be working but isn't (and that excludes app-specific or
Plone objects if possible so that we can turn it into a unit test)
I can try to look at it here.
thx,
Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Brian,
I tried hard to recreate the problem in isolation but failed. So it must
be something whith what we are doing.
Strange that our code works fine with 2.62.
thanks again
Robert
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
