On Mon, 19 Apr 2004 10:16:08 +0100
Chris Withers <[EMAIL PROTECTED]> wrote:

> Hi there,
> App.Management.Tabs.manage_workspace sucks as I've described in
> http://zope.org/Collectors/Zope/1286:
> 1. manage_workspace is only protected by the Authenticated role, and
> that is done directly, not even through a permission.

I think that is probably because this method is an abstraction for the
default managment screen. It does not know what the correct permission
is, but assumes you at least must be logged in to see any management

What are you suggesting to do about this?
> 2. self.filtered_manage_roles then limits the options of what can be
> shown, which might end up being nothing. But, because the method is
> only protected by 'Authenticated', no chance is given to specify other
> user credentials (say, from a user folder higher up in the tree) which
> might be able to see something.

Can you give a concrete use case for what you describe?
> 3. There's a bare try/except which masks errors. From what I can see,
> it should ONLY catch IndexError's.

Yep, bare excepts == bad. Kill it.
> 4. The "raise TypeError" could do with some explanation.

> 5. The Unauthorized could raise a more helpful message "You are not
> authorized to view an of this object's management itnerface"

-0, I think it may be better to say nothing which discloses less
information to would-be attackers. Perhaps VerboseSecurity might be able
to elaborate, I dunno.
> What do people feel about the right way to solve this? 3,4 and 5 I'm
> comfortable with fixing, but I'm stumped as to what "the right thing"
> is to do on 1 and 2 which combine to create a thorny problem.
> The semantics I want are: "Show the 1st management tab the user is
> allowed to see, if they're not allowed to see anything, check if a
> user of the same name further up the userfolder tree can see anything"

Why? Is this consistent with behavior elsewhere? Are you concerned that
lower user folders could lock out global managers by creating
non-privileged users with the same name locally? I say YAGNI unless this
behavior is somehow inconsistent.
> Is that right? If so, how do I go about implementing it? Finally, what
> branches should I do this on?

2.7 and the HEAD are likely suspects for bug fixes. I doubt there will
be another 2.6 release.


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

Reply via email to