How extensible is AuthKit?

[Jamie]

I'm working on porting an old PHP project of mine over to Pylons. For
authentication this project mainly uses a lot of Postgres stored
procedures. As well as checking valid login attempts, the database
generates and tracks authentication tokens that are stored client-side
in cookies. Each token is calculated by hashing the username, ip
address, useragent, and some other stuff. Current valid tokens are
stored in a db table. The cookie expiration (token timeout) is
automatically updated each time the token is used, up to a maximum
lifetime. If I expect to port this app over successfully, this
authentication system cannot be altered at this time.

I know that I can use a customized authentication backend with
Authkit, but I'm not sure that it's made to be tweaked this throughly
(short of essentially forking it...meh). But I do like middleware-ish
features like the decorators and intercepting HTTP status codes.

Should I roll-my-own solution now and maybe port it over to AuthKit
down the road, or can I drop-in the functionality I need without
murdering the existing code too much?

[James Gardner]

Hi Jamie,

It sounds like you already have a farily sophisticated setup so I'd
recommend rolling your own but using the AuthKit code as an example
for anything you wish to build yourself.

One tip though, I now believe using exceptions to trigger the 401 and
403 responses and then intercepting them in WSGI middleware is not a
good design pattern. New code I'm working on generates a normal
response in the authorization decorators or whereever the check fails
instead of in the WSGI middleware. This avoids problems with other
middleware components intercepting exceptions when they aren't
supposed to and also avoids issues around the WSGI middleware trying
to generate a page using objects which are only available where the
exception was raised. It is just less tangled so I'd recommend you
avoid using exceptions in your own code too.

Cheers,

James

(AuthKit author)

[Jamie]

James,

Thanks for the response! I'll do as you recommend.

[Matt Feifarek]

On Mon, Jan 4, 2010 at 11:57 AM, James Gardner <ja...@pythonweb.org> wrote:

One tip though, I now believe using exceptions to trigger the 401 and
403 responses and then intercepting them in WSGI middleware is not a
good design pattern. New code I'm working on generates a normal
response in the authorization decorators or whereever the check fails
instead of in the WSGI middleware.

Interesting. Does this mean that you return a 200 status for bad auth, or that you return 400 status errors and tell the StatusCodeRedirect not to eat those 40x code errors?

I know that this was argued about at some length on the list a year ago or so... don't want to re-hash that discussion. Just wondering what your new recommendations are.

[Mike Orr]

I think by "normal response" he means a normal 401 or 403 response.
In controllers you should be able to call abort(4xx or 5xx) and have
the right thing happen. Abort raises HTTPException (defined in
webob.exc), although I'm not sure where they're being caught. It's
not in StatusCodeRedirect (which I always comment out in my
applications because I'd rather have plain white error messages) or
ErrorHandler (because I get the same behavior whether it's commented
or not). There's no 'except' in pylons.wsgiapp, just try/finally.
The only other one I could find is in paste.httpserver, which writes a
text/plain "Internal Server Error" for any unhandled exception.
However, HTTPException is already caught by that point.

If AuthKit does not depend on Pylons it would not be able to call
abort(), so it would have to set the status manually.

--
Mike Orr <slugg...@gmail.com>

[Jonathan Vanasco]

i don't like AuthKit ( no offense James ! - it's just never served my
needs ) and have had to integrate with systems like you describe.

so the tips i can give are this:

- create your validation and cookie-set/expire functions in something
like app/lib/helpers/auth.py
- put the logic you need in an abstract BaseController that your real
base controllers inherit from
- use class variables like self._auth_required to turn the auth
routine on/off on the BaseController

if you contact me offlist, I can give you my BaseController and sample
derivative classes