The way you identify a user is to pull the 'repoze.who.identity' out of environment variables. The way you detect a failed login is to check whether the login count, passed as a query string in a specially named __logins variable, is greater than zero. This especially seems like an ugly hack to me.
Oh, and I really didn't like the fact that the latest release of repoze.who (2.0a1) has a ton of undocumented, backwards incompatible API changes. It was amusing trying to get it working, only to realize that the docs only referenced a much earlier release.
I understand the goals of repoze.who and think they've written a very impressive set of plugins, and I understand how it would be useful if your app happened to have multiple types of authentication that made sense to handle at the middleware level: HTTP Basic or LDAP or whatever.
But they've done that at the expense of keeping the base case simple: having a user model with a username and password that authenticates at the application level with a login form. 99% of websites use this approach so I was surprised that it wasn't simpler to do, especially coming from Django where this feature ships by default.
Comments
The main thing I didn't like about it was the way it uses environment variables and query strings to pass around information. E.g. take a look at this: http://code.gustavonarea.net/repoze.who-friendlyform/
The way you identify a user is to pull the 'repoze.who.identity' out of environment variables. The way you detect a failed login is to check whether the login count, passed as a query string in a specially named __logins variable, is greater than zero. This especially seems like an ugly hack to me.
Oh, and I really didn't like the fact that the latest release of repoze.who (2.0a1) has a ton of undocumented, backwards incompatible API changes. It was amusing trying to get it working, only to realize that the docs only referenced a much earlier release.
I understand the goals of repoze.who and think they've written a very impressive set of plugins, and I understand how it would be useful if your app happened to have multiple types of authentication that made sense to handle at the middleware level: HTTP Basic or LDAP or whatever.
But they've done that at the expense of keeping the base case simple: having a user model with a username and password that authenticates at the application level with a login form. 99% of websites use this approach so I was surprised that it wasn't simpler to do, especially coming from Django where this feature ships by default.