Posted by benjohnson in AuthlogicAug 13th, 2009 | 12 responses
So I’ve been thinking about Authlogic lately and here are a few ideas I’ve been bouncing around:
- Split out authenticating into “authenticators” that extend a class that acts as an interface, which would obviously be provided by Authlogic.
So you would have a cookies authenticator, session authenticator, params authenticator, twitter oauth authenticator, openid authenticator, anything you want. You could basically create an authenticator, register it with authlogic, and then you can do whatever you want in that class. This shouldn’t be a complicated task, more importantly I think it makes it easier to extend authlogic with different authentication methods.
- Abstract the interaction with your models.
This is especially hard because there is no standard between the different database libraries. But it would be nice to use Authlogic with DataMapper, MongoMapper, etc. I’m just hoping I can come up with a clean and clever way to do this. The only sure fire way that I can think of is to create adapters for each supported library, which means maintaing duplicate code. That would not be a fun task.
- I’m toying with the idea of adding in common application code that you can include in your application.
Such as resetting passwords, registering, logging in and out, grabbing the current user etc. What I don’t like about that is that now I am stepping into your application and making decisions for you. Is this a bad thing? I don’t know, thats for you to decide, but it definitely deviates a little bit from the “rails way”. Your UserSessionsController should look VERY similar to your other RESTful controllers. If you are willing to create those controllers / views, what’s the big deal with creating one for UserSessions? I just feel like it fits better. Here I have an application full of RESTful controllers where the code is pretty similar, then I have this UserSessionsController thats different. I just don’t like that. Also, what if you are using something like resource controller, inherited resources, or resourcelogic? What if you want your controller to use on of those libraries?
The worst part about this idea are the views. Interfaces can be quite a bit different from application to application. How do I provide views that are suitable for every project? In my opinion you can’t. I could give you a million partials, tons of configuration, a lot of helpers, etc. This might add some flexibility, but this seems like a hack. It’s not a clean solution. This is the one thing that I just don’t like about rails engines. I prefer tools that help me create my views. Give me a set of tools so I can go easily create my interface, but don’t go create my interface for me. And I think rails does a pretty good job of this with things like form_for, etc.
The bottom line is that I want to keep Authlogic focused on the business logic behind authentication. You should be able to use Authlogic in a rails app, merb app, sinatra app, etc. All of the interface cruft should probably be in a separate gem or in a template. The thing is, this gem could be written a million different ways depending on your preferences. Maybe I can create a base rails engine that people can fork and modify to their liking. That’s the beauty of git.
To conclude, #1 is probably going to happen, I want to do #2 if I can figure out a good way to do this, #3 is still up in the air and more likely to be in a separate gem / plugin.
That’s it for now, I figured I would try to keep everyone in the loop. Maybe you can help me out or have some ideas of your own.