[Zope-CMF] [dev] CMF 1.4 alpha

Hamish Harvey (David) david.harvey@bristol.ac.uk
Thu, 27 Feb 2003 16:49:16 +0000

On Thursday 27 Feb 2003 4:01 pm, Tres Seaver wrote:
> The "View" permission on any Zope object is the moral equivalent of the
> Unix "execute" permisison;  the only sensible way to treat it on
> TypeInformation objects is as protecting the "factory" / "constructor"
> that the TI is a proxy for.


> *Don't* try to use the TI to control visibility of the content objects;
> use the workflow states' security tabs for that (workflows already
> indirect through the portal_type, and they make enforceable assertions
> about the role-permission map on their instance).

That makes a lot of sense. So, in short, the current behaviour *is* broken, 
and stops people from being able to view types they can't create, but the 
approach to fixing it I put forward isn't the right one. I can live with 

> > Setting permissions on the TI does nothing by itself for the instances.
> > An instance marked as "not visible" by that View permission mechanism is
> > still visible if you know its path.
> I don't like the current use of the TI's "View" permisison to fake out
> filtering in folder_contents;  I would prefer to have it just use "skip
> unauthorized", with *real* security assertions assigned by the workflow.


> > - controlling viewability of the TI: there, View is fine. But what does
> > "View the TI" mean? A user has to get hold of a TI if it wants to check
> "View" permission is "execute", not "read";  "Access contents
> information" is a better map for Unix' "read".  Once you have actually
> gotten hold of an instance, you *must* be able to query its TI;  trying
> to protect the TI instead of the instances is a recipe for hair loss.

But here we hit a problem - the same one as before, surely. If make a TI 
non-viewable to a role in order that that role cannot execute the factory 
method for which the TI is a proxy, doesn't that also mean I can't query the 
TI of an instance of that type?

> > Ok so I guess my position is now that an "Add instances" permission is
> > fine. Let's not reuse other permissions, it's not clean.
> I don't think there is any sensible use for the "View" permission *on
> the TI object itself* which means anything beyond the notional "Add
> instances" permission.  I can live with "Add instances" if it aids
> understanding, but it grates.

If "View" on the TI can be used to control creation of instances, without 
blocking the visibility of those instances once they are created either with 
the full URL of the instance or in folder listings, then I for one am quite 
happy that this is logical and clean.