On Fri, Mar 28, 2008 at 10:19:35PM -0700, Mike Orr wrote:
> Their argument seems to be not that it doesn't work (the previous
> bugs have been fixed), but that you can write your own authentication
> in the time it takes to learn it. I haven't used AuthKit in a program
> so I can't say definitively one way or the other. As for the number
> of AuthKit discontents, it's impossible to say whether they're a
> substantial percentage of the Pylons userbase or a small number of
> loud activists.
I recently attempted to upgrade an existing application from an ad-hoc
authentication and authorization framework to AuthKit. In the end, I
decided my ad-hoc method was better. I'm not an AuthKit expert,
though I did give it a good try. Here were my reasons:
1) Bad documentation is worse than no documentation. Much of the
AuthKit documentation is out of date enough that it leads you down the
wrong path. The API reference are more useful than the examples, but
they are very difficult to follow, without being familiar with the
guts of AuthKit.
2) The only way I could determine to get style control over the login
screen (the "forward" method), was very complicated to implement. As
Mike said, complicated enough that I could write my own middleware to
do it in a similar amount of time.
3) What's worse is that I could never get "forward" authentication
working. The nice decorator syntax and uniform authorization API was
what I wanted, but I couldn't get to that point.
> AuthKit is probably most helpful if you have a complex permissions
> scheme and use the built-in plugins. It's less helpful if you use the
> "forward" feature to call back into the application for the login
> form. In that case you're doing most of the work yourself anyway and
> merely shoehorning it into AuthKit's API.
I agree with you 100% here, but I'll take it a step further.
Authkit's API is what's great about it. But who wants to choose
the barebones login screen it provides or an HTTP authentication
window? Is that really a common use case?
AuthKit's ability to express complex permissions for authorization is
really awesome, and it's where I see a lot of the value - the API is
very well considered. But getting an app with a custom login screen
converted over to it was enormously difficult.
> In that case you have to
> ask whether five lines of AuthKit API calls is really better than five
> lines of homegrown code. Probably not, and I think Gardner would
> agree here.
For complex permissions, this is a gross underestimate. My app
(though it could use some refactoring at this point) has hundreds of
lines for permissions between different roles and groups of users. It
includes LDAP interaction to get that data. It also has really ugly
hooks into the controllers to verify a user.
The object model of roles in AuthKit is the value - it's a lot like
RADIUS/TACACS+ if you're familiar with the router kind of AAA model.
I found that it wasn't trivially easy to reproduce that.
> I see that AuthKit does both,
> but I'm not sure how well it cascades from one to the other, or
> whether it will accept my existing Users table.
It does? I couldn't find any information on linking AuthKit with LDAP
(without writing my own objects to do it). And most of the
information I could find on using a database table seemed to be about
people unable to get it working. I had good luck with statically
configured users, but this doesn't scale.
In summary - it might just be a documentation issue. I really like
AuthKit's ideas. They seem very "correct" to me. It's just too
difficult to integrate into an app.
--
Ross Vandegrift
[EMAIL PROTECTED]
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
