I have just concluded an epic two day struggle with Zope's security
machinery. I think I've won, and wanted to find out whether anyone else has
had similar problems.
        I had defined a Python product that worked very nicely. I was able
to add and delete my objects and edit, copy and export them perfectly well.
But when I tried to rename, paste or import them, I got an exception saying
that "The object X does not support this operation".
        It appears that security checks for permission to add an object to a
Folder is done differently by the Product Add machinery and the CopySupport
machinery that paste/rename/import use.
        I had defined my constructors slightly unconventionally in
__init__.py. Redefining the constructors more normally solved my immediate
problem, but it doesn't remove the source of Zope's inconsistent behaviour.
More details of the diagnosis are at the end of this email, for those who
are interested.

Is this something I should put in the collector?

One happy result of this mess is that I am now on a first-name basis with
about 80% of the Zope source code!

Stephen Simmons, [EMAIL PROTECTED]
HealthArena B.V., Amsterdam, The Netherlands
phone +31 20 486 0555; mobile +31 6 1505 3086; fax +31 20 486 0559

Problem copying/pasting and renaming

I was able to create new instances of my Element class, but whenever I tried
to rename, cut/paste or import the objects, _verifyObjectPaste() in
CopySupport.py raised a Copy Error (The object X does not support this

_verifyObjectPaste() performs three checks:
(i)  The container is happy having an object of this type being pasted into
(ii) The user is allowed to create new objects of this type
(iii) The user is able to access the object being pasted or renamed

All three conditions were true, so there is no reason why renaming, etc
should be prevented. Especially when I could create objects as desired
through the management screens.


The problem was traced to the unusual way I had defined the constructors in
__init__.py and the class's module. It appears that
getSecurityManager().validateValue(meth) does not exactly duplicate the
check done when adding a product instance.

Originally, I removed the constructor definition tuple from __init__.py:
  def initialize(context):
   """Register Element"""
    constructors = (PlatformElement.Element), # Specified indirectly!
    icon = element.gif

and put it at the end of my class definition module, PlatformElement.py:
  class Element(Folder):

  def manage_addElement(self, id, name='', title='', REQUEST=None):
      """Create an Element"""

  Element_constructors = (
   ('manage_addElementForm', HTMLFile('Element_add', globals())),
            ('manage_addElement', manage_addElement),

In this case, check (ii) was failing at line 390 of CopySupport.py when
trying to validate the constructor

The problem was fixed by changing the constructor definition to the more
conventional form:

In __init__.py:
  def initialize(context):
   """Register Element"""
           constructors = ( # Specify constructors explicitly!
     icon = element.gif

In PlatformElement.py:
  manage_addElementForm = HTMLFile('Element_add', globals())

  def manage_addElement(self, id, name='', title='', REQUEST=None):
      """Create an Element"""

While this fixes the problem, it leaves unresolved the question of why
Zope's security machinery was happy using the original constructors but
barfed when checking whether it could use them.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to