[ZPatterns] LoginManager auth type screwiness

[John Eikenberry]

Sorry, I was mixing our conventions with zope implementation issues. Of
course you're right, and I'm not sure if I want to base code on one of our
conventions. I don't have the option of copying the index_html into each
folder, it would conflict our content layout system.

Maybe I can add a hook to bobo_traverse into our publishable object
classes. Check validation while traversing. I may give that a try, but I
kind of doubt it working.

In the end I guess we'll probably just have to have a landing page for
cookie based auth. :P

Phillip J. Eby wrote:

> 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.
> 
> 
> _______________________________________________
> ZPatterns mailing list
> ZPatterns@eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/zpatterns

-- 

John Eikenberry [jae@kavi.com]
______________________________________________________________
"A society that will trade a little liberty for a little order
 will deserve neither and lose both."
                                          --B. Franklin