[Zope-CMF] PortalContent permissions

[Shane Hathaway]

On Tue, 17 Apr 2001, seb bacon wrote:

> Either it's not working the way it should, or I'm misunderstanding
> something.  If I create a 'foo' method and add it as the first action
> on a Type, with a permission mapped to something Manager-only, and
> publish it, I still see the 'foo' as an anonymous user.
>
> I can't see any code in the TypesTool which provides for
> mapping the permission in the 'actions' structure to actual
> permissions.  How is this meant to work?

The permissions you set up in TypesTool are only meant to be "hints": if
the user doesn't have the specified permission, they won't be shown the
links to get to the view.  The views themselves are all in skins, so they
can't be (and shouldn't be) protected directly.  Presumably somewhere else
the user is actually restricted from accessing or using the information
provided on the page.

For example, the editNewsItem.dtml page might be perfectly safe for anyone
to view, but if anonymous users clicked the "change" button, they would be
denied access.  With the permission set in the types tool, they won't be
shown the link to editNewsItem.  It's a UI feature, not a security
feature.

>
> > What do you think it should do?  I was thinking it should first look for
> > a "view" action, but if the user doesn't have access to it, it should
> > look through the options in order and choose the first action the user
> > is allowed to access.
>
> I can't think of any benefits to having a default view called 'view' -
> it might be better to rely purely on the rank of the action, rather
> than hardcoding in an exception to the rule, I think.

It's not hardcoded since the ID of an action is not linked to the name of
the action as displayed to the user.  An action might have an ID "view"
but a name "Edit".  What *is* hardcoded is the "view" method of all portal
content and the fact that it is exposed in URL's.  But we could find no
way around that.

>
> > > And as a bonus question, what does the following, from PortalContent,
> > > acheive?
> > >
> > >      index_html = ComputedAttribute(_index_html, 1)
> >
> > It exposes _index_html as a computed attribute named index_html, with
> > the bonus that the "self" passed to _index_html is an acquisition
> > wrapper (that's what the "1" does.)  This is necessary to make skins
> > work.
>
> Thanks for the explanation, but this remains voodoo, as I have not
> acheived the requisite level of ExtensionClass or Acquisition nirvana
> ;)  At the risk of being off-topic, but perhaps to the benefit of
> others, what is a computed attribute?  Or another way of putting it,
> why would exposing index_html as a normal method not work?

Computed attributes let you call a method automatically when a certain
attribute is accessed.  It was done this way to avoid duplicating some of
the code in ZPublisher.  When ZPublisher finds a method, it looks at the
method's signature and tries to fill in all arguments using the REQUEST.
If PortalContent.index_html were a method, we'd have to put code in
PortalContent for looking at the skinned method's signature and filling in
arguments, again from the REQUEST.  Instead, as it is now when ZPublisher
asks for the index_html attribute it actually gets a skin object and looks
at its signature.  It's much cleaner this way.

Shane