In case you missed it on the Django lists, RSS feeds, and other good tidbits – Simon Willison posted about, and made available, code to enable pretty much any Django based site to take advantage of OpenID.
He took a really interesting tack – instead of tieing OpenID into the authentication system that comes as a part of Django (contrib.auth), he overlaid the session tidbits with a middleware component that passes information into your views (and potentially your templates) as an extension on the request object. So instead of using the Django auth mechanisms for your OpenID users, you can let it ride without permissions and really even heavy tracking of those users just through their OpenID.
Obviously that may not be quite what you’re looking for, but in taking advantage of enabling some light level of authentication and identity to a public site, it’s really in a sweet spot.
I was really impressed with is how he packaged the whole kit for someone to take a look at, learn, and use. First off, there’s a great “single-page” documentation page right in the source, along with a .txt counterpart. The in addition to the core code itself, he packaged up a super-light django “example” application that most folks will be able to pull down and immediately fire up to get a sense of what it is doing and how to use it.
In working with Fritz to implement TrenchMice’s OpenID consumer support, we ran into a number of problems when we bound OpenID into the heavier weight contrib.auth setup. “Required” fields were not always returned from the OpenID provided when requested through the registration extensions, and he ended up iterating on the process a couple times to finally route the OpenID registration process into their normal registration process when there wasn’t enough information to fully process things.
Clearly, if you don’t need the heavier weight (contrib.auth) setup, Simon’s contribution will be a godsend to your application.
Rhonabwy 
Thanks for the write-up – I agonised over the details of that package for far too long, so it’s great to see that they are appreciated. I actually deliberately avoided including obvious support for sreg required v.s. sreg optional precisely because I’ve seen that distinction cause trouble for sites like TrenchMice in the past. I’ve got a few ideas for ways to get contrib.auth integration in, possibly including co-operation with James Bennett’s django-registration package.
LikeLike
The talk was pretty good, it filled in some gaps for me about OpenID. We used the examples from the actual library and were able to get it working for us. We added a field to the users table “openid_key” and made username/password optional. It then requires either openid_key to be set, or username/password to be set. When they log in with their openid key and do not have a username set we force them to choose a unique username.
LikeLike