DHH, creator of Rails, drew attention to my least favorite aspect of the framework in his wrap-up of the recent Snakes and Rubies throw-down.
To me, such an elaborate administration interface with login, permissions, and groups and what have you is out of scope for inclusion in the core framework.
Show of hands, how many deployed Rails apps have no concept of users?
I’m sure there are some, but the majority have some sort of registration, login and authorization. How many programmer hours are going into either re-inventing the wheel or customizing existing solutions?
Worse, a lot of projects will start with one of the many existing solutions only to realize too late that they need something different. Then they wind up having to maintain a customized solution that doesn’t participate in the network effects of community development.
There is a “less software” solution to this complexity.
Here’s what you do: Make an ActionUser module part of the Rails core. Add a good API for ActionController and ActiveRecord to authenticate methods against the current user. That’s it.
Just as important, here’s what you don’t do: Don’t implement permissions. Don’t implement roles. Don’t implement ACLs. Don’t create fancy permission management views, or even login controllers. That doesn’t belong in the core framework.
Just like ActiveRecord is database-agnostic, allow people to write pluggable auth. modules so that do the dirty work. Need to authenticate against LDAP? Make ActionUser::LDAP. Just need to keep anonymous users out of an admin section? Make ActionUser::Simple. Need to authenticate with cookies, or HTTP auth, or Kerberos? Interchangeable modules. Develop locally with SQLite and HTTP auth, then deploy to production with Oracle and Kerberos.
I know DHH isn’t interested in including this in the core, but it’s not like ActionMailer shows up in Martin Fowler’s Patterns of Enterprise Application Architecture. With so many different auth projects going on I can’t help but think that a standard interface for auth would benefit the community as a whole.
Am I the only Rails developer sick of repeating myself, cobbling together auth for each new project?
4 responses to “What infuriates me about Rails”
I don’t understhand this thinking: “Am I the only Rails developer sick of repeating myself, cobbling together auth for each new project?”. If you’re making the same authentication code each time, why are you not just abstracting this for yourself?
What I’m saying is that what works for you won’t work for me. At 37signals, every single application has a different way of doing users and authentication. That’s not because we’re sloppy or don’t know how to abstract, but because the business objectives and mechanics of the applications differ.
So when we at 37signals can’t even find a way to abstract users and authentication for our own applications, I hold little faith in the notion of a generic model that’s supposed to be what “most people need most of the time”.
In conclusion: If you’re seeing repetition in your application, abstract. Just don’t assume that the repetition you see is a widespread syndrom.
David, thanks for taking the time to respond!
I like to think I’m abstracting as best I can, but I’m lazy and would like to re-use someone else’s work (and benefit from them running into bugs before me) too. However I’m also not about to start yet another user system project for fear of fragmenting the developers interested in this problem even further.
A lot of the problems with users have been encountered before, and some haven’t. I think this is an opportunity for a convention for the solved problems.
Based on what I’ve read from you, I think our philosophies differ and you definitely have the benefit of more experience with Rails to back up yours. The most productive thing for people in my camp to do (aside from complaining about Free software in our blogs) may be to work on interoperability for the existing auth systems without the authority of being part of the core. Hopefully that will result in something worth inclusion in the core.
Finally, at least I’m not bitching about table pluralization 🙂
Signups and logins are user-hostile.
Extract code you reuse. Be honest and pragmatic about it.
Developers are deeply afraid of their application, so they hide in the plumbing (see 2)
“1. Signups and logins are user-hostile.”
So should, like, Basecamp not have user logins? I agree that they are often not necessary, but practically speaking, they often are. The key is to make them as unobtrusive and out-of-the-way as possible … So not every Rails app will need a basic user model, but not every Rails app needs a database…