[ZPatterns] LoginManager auth type screwiness

Phillip J. Eby pje@telecommunity.com
Thu, 21 Jun 2001 19:54:20 -0500


At 01:48 PM 6/21/01 -0700, John Eikenberry wrote:
>
>Fixed this by modifying the validate method on LoginManager. Just after the
>user object is retrieved from the loginMethod and before the user existance
>check (around line 242) I added this:
>
>        if parents:
>            for p in parents:
>                if hasattr(p,'__roles__') and \
>                        (len(p.__roles__) < len(roles)):
>                    roles = p.__roles__
>                    break 
>
>This restricts the roles of the checked item to the most restrictive in the
>traversal path. The len() test works because the applied permissions will
>necessarily be a subset of those of its containing parents (you can't add
>permissions further into containment, only take them away).

I really wouldn't recommend this patch, as IMHO the behavior you're relying
upon is not really guaranteed - certainly it's not guaranteed by anything
in ZPublisher or the Zope security mechanism generally, and Python products
or even possibly built-in Zope objects may violate it.  Jim Fulton once had
a proposal out there to *change* Zope/ZPublisher to a scheme under which
your assumptions might be more valid - but Zope is not that way now, and
even if it were, it would not guarantee that a longer __roles__ list was
inclusive of a shorter one - it would only be requiring that a user have
one of the roles expressed at each level in order to traverse further.
(That change would also fix this issue, since the user would be
authenticated *before* they could traverse past the subfolder to get to
index_html.)

Anyway, the problem behavior you're seeing is an issue with how roles are
acquired, and I know Ty and I have run into it once before.  I do not
remember whether there is a fix for it besides copying the index_html
method into the subfolder, however.  I think you will see the behavior with
*any* user folder that wants to pop up a login form when something isn't
authorized for access, and as such it might be reasonably considered a Zope
bug.