On Jun 21, 2010, at 9:31 AM, Wyatt Baldwin wrote: > Would you be interested in posting your one-hour-auth solution? I'm > about to go down this road (roll my own vs repoze vs ?), and seeing a > simple roll-your-own example would be helpful, even though I know I > can figure it out myself. Also, is this solution authentication only, > or is there an authorization piece, too?
I have such a solution in the open-source code that power the Kai website. Auth decorators: http://bitbucket.org/bbangert/kai/src/tip/kai/lib/decorators.py Base controller that checks for the user (and sets up timezone and Babel format objects for l10n and i18n): http://bitbucket.org/bbangert/kai/src/tip/kai/lib/base.py#cl-31 And of course, for password hashing, I have two methods on the User (Human in my case) model class: http://bitbucket.org/bbangert/kai/src/tip/kai/model/human.py#cl-71 hash_password and verify_password. It should be pretty obvious how to copy these over for use with SQLAlchemy. This is generally the part that trips up people from a security perspective, poor password hashing. Ideally if you want to be really secure in your hash, you'd use bcrypt as was suggested by Eugene. Also, rather than using a single salt for every single hash, its highly recommended to generate a salt for each and every hashed password. This way should your passwords be exposed, they can't generate rainbow tables for your salt and then break them all, they'd have to do that for each and every one of them. The unique salt is stored along with the hashed password in the db. The scheme I usually follow is what I laid out here. I do a session check for the user in the BaseController and attach the user object to the tmpl_context (Because I usually need the user info all over the place). This also puts it somewhere for use when the decorators check for it before an action is run. Kai stores the logged in user's db id in the session (which is tamper proof when using a secret key with Beaker), but an alternative which I've done with some sites to avoid storing any info like that client-side, is to have a table like this in your database: Sessions session_id - user_id - login_time You can then insert into there during login time, and query it to look up the User given the session id (session.id). It also makes it easy to do things like restrict how many times a user can login since you can find out if a user has multiple active sessions going at once (if that type of thing is desired). As Eugene said, this stuff goes pretty fast, I usually copy/paste the decorators, and the password hashing functions from project to project, and tweak/update as needed. Setting up how the user logs in, and is handled has always been unique to every app I've done, so that stuff didn't lend itself to copy/pasting over. Cheers, Ben -- 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.
