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.

1 and 2: Sounds good as long as it doesn’t take abstraction to a Java level.

3: I think you should have (optional) generators that would generate controllers and views with a sensible default for those items that are usually same from application to applpication. I don’t think that deviates from the Rails way, but instead gets closer to it. It’s like how David said at the Rails conf in Las Vegas: When you order a burger, you expect it to contain all the standard things on a burger unless you specifically say you don’t want something on it. A small set of sensible defaults that anyone can change is a good thing. Whether as a separate gem or as part of the core is a good idea since I end up copying the views and controllers from your example app for every new app even though I modify them later. They are just sensible defaults, IMHO.

Oh, and I’m not advocating big scary generators like restful_authentication. That thing was like a horror movie. I mean something that will generate a small and simple but working shell that can easily be customized.

Definitely agree that you should abstract to support different ORMs. Datamapper will be gaining a much larger following when Rails 3 is finalized. I’d imagine someone as clever as yourself could come up with a nice thin abstraction layer/interface model to cover the differences between ORMs that Authlogic is concerned with.

One thing you mentioned is compatibility with any framework… You could accomplish this by allowing AuthLogic to be used as a piece of rack middleware. I like the model used by CloudKit for authentication middleware, take a look for some inspiration.

Yeah, I like data mapper a lot too. So far I really haven’t had that many issues with ActiveRecord and it gets the job done remarkably well, but I do agree data mapper is put together better. Anyways, one of the solution I was thinking was to make another library that you could use that served as an abstraction layer. This way authlogic could use it and so could other libraries. I think this would be a good addition to the community and might help other libraries accomplish the same thing. The big down side is that this would be pain in the ass to maintain.

#2 – If you get it working once, and it breaks between the adapter and the ORM, then IMO, that’s for the ORM makers to handle (since they broke their public API). As long as you have tests, and the ORM does proper deprecation, shouldn’t it be fairly easy to keep things working between versions?

#3 – I’d prefer well maintained tutorials in the codebase (under docs/ or something) to be honest. I liked the fact that views/controllers weren’t generated (because I ended up using non Rails standards anyway, like for example, utilizing formtastic).

@Kieran P: My idea for the generator is it would be 100% optional to ever run it. It’s just there to generate the defualt controllers and views for various parts of an auth system using Authlogic if you want. You can still continue using Authlogic without ever running a single generator if you don’t want it, just like it is now.

A lightweight generator would be useful for generating the controller and view for session management, password reset, account activation, etc. ONLY IF you want to do it the way it’s in the docs already instead of copying and pasting from there.

Nobody complains about the ./script/generate controller and all the xml format and code comments it puts in your controller that most people delete. It’s just the default and people edit it. The same can be done for Authlogic. Since it’s frameword agnostic, it’d make sense to use a separate gem for it though.

“Anyways, one of the solution I was thinking was to make another library that you could use that served as an abstraction layer. This way authlogic could use it and so could other libraries. I think this would be a good addition to the community and might help other libraries accomplish the same thing. The big down side is that this would be pain in the ass to maintain”

Actually, this kind of like what rack does between web servers, and web frameworks. But this would instead be between applications, and ORM libraries.

I think the challenge would be in coming up with a nice api for apps to use, and still be consistent with different ORM layers.

And it doesn’t have to be that hard to maintain, if you put the responsibility on the ORM developers/users to maintain adapters for this library.

Seems like too many layers though. A layer to abstract the database is fine, but a layer to abstract the layer that abstracts the database? Perhaps going too far? It may be better if everyone just simply used datamapper, and that was the sole abstraction layer to any underlying database you might want to use.

I’ve watched a screencast, read a few tutorials and tried a demo…now it’s time to add the AuthLogic functionality to an existing app. So far, it seems pretty straightforward but I did want to let you know about one concern. I’m using an Oracle database and when I try running “rake db:migrate”, I receive the following message…

/*—————–*/
rake aborted!
An error has occurred, all later migrations canceled:

Basically, the “add_index :users, :persistence_token” line in my migration is causing the migration to fail since the generated index name is greater than 30 characters (which is Oracle’s limit).

I’m not sure if this is something that’s may be fixed in Authlogic or if it’s something that must be fixed in Rails and/or ActiveRecord. Still, I thought you might want to know.

All of that aside, I really like this gem. Thank you very much for the great work! It’s very helpful.

About Me

My name is Ben Johnson and I'm a programmer. Binary Logic is my personal company located in the NY area, I am also a partner at Concierge Live, a corporate ticket management company. I love solving problems with computers and coming up with elegant / simple solutions. Checkout my portfolio and open source projects for examples of my work.;