local grants don't work properly for objects with object fields

Bug #98287 reported by Andreas Reuleaux
4
Affects Status Importance Assigned to Milestone
Zope 3
Won't Fix
Critical
Christian Theune
3.4
Won't Fix
Critical
Christian Theune

Bug Description

Steps to reproduce this bug:
Install the families pkg provided in families.tgz,
this allows you to add two different components
Family and SimpleFamily in your ZMI.

Note that they differ in their interfaces in the way the mother (and father) fields are defined:
  mother=Object(...) in IFamily vs.
  mother=TextLine(...) in ISimpleFamily

They are both protected by the same permissions/roles:
  * in order to view families (simple families) one
    needs families.View permission, respectively
    the families.Reader role
  * to edit them families.Edit permission is required
    respectivley the families.Editor role

Add a folder (say "folder") somewhere in your ZMI content space and within that folder some Family and SimpleFamily
objects (say "family" and "simplefamily") - at that point permissions don't matter yet - i. e. I added these objects as a previliged user with the zope.Manager role.

Make the folder a site and create a local user within that
site. This involves creating a pluggable
authentication utility (say pau) within the site
management folder (registering it), a prinicpal folder
(say users) within the pau (registering it, going back to the configuration of the pau now using the users utility as an authenticator plugin and Zope Realm Basic Auth as Credential plugins) and creating a prinicpal within the users principal folder (say a user "local").

Go to folder > Grant, search for the newly created local user in
  /folder/++etc++site/default/pau/users and select him. Now grant him the families.Reader and families.Editor roles

Create two more users say reader (with the families.Reader role) and user (with families.Reader and families.Editor roles) in your principals file. For convenience these are
already provided in extra/families-principals.zcml, you
can just include this file your principals.zcml with
<include file="families-principals.zcml" />

Now you have 3 different users: reader and user from
your principals file and the local user of the folder
site. Note that the"local" user of the site has the same roles (permissions) as the "user" from the principals file.

Now try to acces the two objects family and simplefamily with these three different users (in a different browser)
(6 possibilities alltogether)

Whereas in the case of simplefamily the "local" user and the "user" from the principals file both have the same behaviour (and that is correct), the "local" user can't view the family object - this seems a bug to me.

As I am still learning about utilities, registration of them etc. there is a small chance that there is a configuration error on my behalf. (I can give even more
detailed explanations of how I created the pau, the users folder, the local user above). If someone prooves me wrong
I would be glad to hear. I doubt it though, as everything
works fine for the simplefamily Object. The problem is only
with the family Object.

Tags: issue security
Revision history for this message
Andreas Reuleaux (reuleaux) wrote :
Revision history for this message
Stephan Richter (srichter) wrote :

Changes: submitter email, importance (medium => critical), revised version_info, new comment

Based on the title, I would say this is a locating issue. I am not sure whether the widget should be responsible for locating the created object. Overall, I think object widgets were a bad idea anyways. ;-)

Revision history for this message
Christian Theune (ctheune) wrote :

Looking into this.

Revision history for this message
Christian Theune (ctheune) wrote :

Ack, looks like a location problem. Investigating the ObjectWidget there already is a place in the code that notes ILocation-support as a TODO. Going to implement this now.

Revision history for this message
Stefan H. Holek (stefanholek) wrote :

I have issues with the current solution. My Object fields containing zope.app.file.image.Images now break with "Cache values must be persistent objects."

This is because zope.app.file.image.Image is not Contained, and the location-proxied Image cannot be persistet.

Revision history for this message
Christian Theune (ctheune) wrote :

I promised to back out this change and I'm about to do that. I'm waiting for a confirmation to do so because this languished for a while and I'm not sure what people are saying today. Especially Stefan's comment confirms that it should be backed out. After that I'm going to set this bug to WONTFIX because of architectural issues.

Revision history for this message
Andreas Reuleaux (reuleaux) wrote : Re: [Bug 98287] Re: local grants don't work properly for objects with object fields

Hi Christian,

OK, fine with me: I have moved all my stuff to z3c.form -
which has subforms - so I don't need object widgets any more.
Thanks for taking the time to look into this.

-Andreas

On Thu, Sep 13, 2007 at 06:07:12PM -0000, Christian Theune wrote:
> I promised to back out this change and I'm about to do that. I'm waiting
> for a confirmation to do so because this languished for a while and I'm
> not sure what people are saying today. Especially Stefan's comment
> confirms that it should be backed out. After that I'm going to set this
> bug to WONTFIX because of architectural issues.
>
> --
> local grants don't work properly for objects with object fields
> https://bugs.launchpad.net/bugs/98287
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>
> !DSPAM:46eaf1a332361690420241!

Revision history for this message
Christian Theune (ctheune) wrote :

Ok, I've backed out the change today and released zope.app.form 3.4.0b2 which doesn't include the change anymore.

Changed in zope3:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.