Al Pacifico wrote:
> I'm fishing around for suggestions before coding some classes for some UI
> logic.
>
> Background:
> I have a set of resources that are available only to authorized users. Who
> is authorized and what he/she is authorized to do is determined by a
> lookup
> in an external resource (for this application, an LDAP directory). The
> level
> of functionality (e.g. "security clearance") depends on the user's
> role(s),
> again determined from the external resource.
>
> What I'm thinking of:
> I'd like to make my content served by Quixote essentially polymorphic,
> determined by the role the user takes. This points me in the direction of
> subclassing a base class for each role. I imagine q_lookup() would call a
> method within a class determined by the client's role.
>
> One reason I'm thinking of this:
> One constraint on non-Quixote technologies is that the html served is
> derived from a XSLT transform of XML data returned by my application logic
> using a cached XSLT stylesheet. (I won't be using PTL at all.) I imagine
> each class will have a set of stylesheets that are class attributes
> derived
> from class methods (pardon me if my OO-terminology is a bit off, but what
> I
> mean is every instance of a given class will share the same set of
> stylesheets, each a singleton). The libxml2 and libxslt modules seem to
> work
> really well for this.
>
> Is this problem really as trivial as it seems?
> Before experimenting with my own ideas, I'd like to solicit ideas about
> how
> others would incorporate this into a q_lookup() method?
> Thanks in advance.
>
> -al
> Al Pacifico
> Seattle, WA
I have some code if you want with a generic User class, then you subclass
it for each type of user. Boolean attributes specify what permissions
that type has. Then in each URL method I call a require_perm('foo')
function to verify they have access. Or has_perm('foo') => boolean. The
functions essentially do getattr(quixote.get_user(), 'foo').
For authentication, I have a list of authenticator objects which are
called in turn. Each takes the username/password from the form and
verifies it some specific way.
SUCCESS: Returns a user object (one of the user type subclasses),
using a default type if no specific type was set for that username.
FAILURE: Display "incorrect password" to user.
DECLINED: The username is outside this authenticator's scope, go on to
next authenticator.
There's an LDAP authenticator and one for a static password list
(dict-based). The LDAP authenticator merely tries to log in as that
person, then a static list determines the user type. But you could read
the user's LDAP properties and somehow calculate their user type from
that.
--
-- Mike Orr <[EMAIL PROTECTED]>
_______________________________________________
Quixote-users mailing list
[email protected]
http://mail.mems-exchange.org/mailman/listinfo/quixote-users
