Those still using TurboGears 1 will find a big improvement in the authentication and authorizarion area when they upgrade to version 2: TurboGears 2 ships with an easy-to-use, pluggable, extendable and well-documented authentication and authorization system, powered by repoze.who and tgext.authorization (whose documentation will be available along with TurboGears’ very soon).
Some of the features include:
- You may store your users’ credentials where you want – in a database, an LDAP server, an .htacess file, etc.
- You’ll be able to store your groups and permissions where you like too, but also use as much as group and permission sources as you need. What if your application’s main database already stores your groups and permissions data, but the company’s IT department needs to reuse their Htgroups file in the application? That would be a piece of cake.
- You’ll be able to manage your authorization settings with an API independent of the used source(s) (databases, Ini files, etc). Yes, add/edit/delete groups and/or permissions.
- You’ll be able to grant permissions to anonymous users (hopefully available this week).
- Do the above and more without writing too much code.
Right now there’s only the SQL plugin, so in the mean time you may still only store your groups and permissions in a SQLAlchemy or Elixir managed database, but very soon we’ll have the Ini plugin (to store groups and permissions in *.ini files) and even more.
In the future you’ll also be able to get OpenId authentication with a couple of lines of code (there’s a work in progress) and possibly OAuth authorization too.
And you may give it a try now! You can either try the latest code from the trunk or wait for the first TG2 beta which will hopefully be released in a couple of days.
I really should finish that OpenID plugin up, right
Hope to have some time this week, shouldn’t be too much left (basically it’s working) but some documentation would be good (well, and tests but testing openid is always a bit tricky due to it’s redirecting nature but maybe somebody wants to help out).
I was also playing around with OAuth recently but the big question is if it fits really into repoze.who. Nevertheless I guess it can make sense as sort of middleware which basically gives you back the token and you can decide upon the token what you allow and what not. But some thinking and discussion needs to go into this (as we did a little on #repoze).
Any news can then be found on my blog.
The stuff you write about also sounds quite cool. Will this also be usable in any WSGI context?
Hi, Christian!
I think it doesn’t fit into repoze.who because r.who only deals with authentication, but it’d be a wonderful addition to the authorization framework I’ve been working on, which I hope to make TurboGears-independent, either as part of the Repoze project or as an independent project.
It can basically work where repoze.who can work, although it has some TurboGears-specific bits. I would wait until it’s fully independent of TurboGears.
Cheers!
I think so, too regarding repoze.who, esp. as in the process the user actually has to login, so the two will mix.
Looking forward to it
(and will keep thinking about how to do OAuth best in the meanwhile).