On 12/9/05, Jeff Watkins <[EMAIL PROTECTED]> wrote:
> Lee, this is a really interesting idea. I hadn't considered it at all when I
> originally developed the identity framework. However, I agree with Kevin,
> it's a really good use-case and I'd like to make it work.
>
> So I need a little more clarification: Do you want only one set of
> permissions? Or will the two controllers be completely disjoint? Meaning,
> the users from controller A will have no permissions in controller B unless
> they have separately authenticated?
>
> Frankly, I don't like the disjoint users idea. I'd rather look at a
> single-sign-on style solution. Maybe with a cross provider credentialing
> scheme.

I'm doing something like that in a Quixote application.  Most users
are authenticated through an LDAP server, but there's a static list
for others in a database.  Everybody has a base permission level, but
a few people have elevated permissions in certain contexts.  I've got
the permission sets arranged in classes, and call a global
    require_perm(perm_name, **context)
or
    has_perm(perm_name, **context) => bool
at the beginning of protected methods.  (This could be a decorator.) 
Or put it in ._q_traverse() to protect entire sections of the site.  I
think TG is going for protecting sections in the config file, but I'm
not sure if I'd like that.  The application almost requred an
anonymous mode with logins, which was pretty hard to do with Quixote's
model.  But in the end we made the anonymous view a separate site.

The TG site I'm working on doesn't need logins,  but I still keep this
use case in the back of my mind.

--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)

Reply via email to