Splitting out some of the authentication code into “authenticators” has worked out great so far. More importantly, its more or less a blueprint for people to extend Authlogic and provide alternate authentication solutions (openid, facebook connect, oauth, etc.).

The last major change I’ve been making is removing validations in the acts_as_authentic module. Validations add some clutter to authlogic, some might say its a necessary clutter, but I’m leaning towards leaving it out. Validation is such an easy thing to do. ActiveRecord provides very simple methods for doing this, I also feel like its gets in the way for certain edge cases. Authlogic will still provide some nice methods to make your life easier, like validating the format of an email address, the main difference being that you have to explicitly implement this validation. No validations will be automatically added. Lastly, this makes ORM abstraction a little easier.

So that’s that. I’ll keep you updated when I start to push out some code and what not. I’m probably going to label this release as v3, because of the validation changes and some of the other major changes that might break backwards compatibility.

I think this is just the beginning though, here are my thoughts….

The Big Picture

Thanks to things like Rack, the MVC design pattern, and ActiveRecord / DataMapper, all of these frameworks look very similar. They all have a similar pattern, which is the inherent nature of the MVC design pattern. So I decided to take advantage of this with Authlogic. Any specific framework implementation is extracted out into an adapter. Similar to how ActiveRecord has an adapter for each database type, except the Authlogic adapters are much simpler.

Probably the main reason these adapters are so simple / similar is because of Rack. Thanks to Rack, there is a request standard across all of these frameworks. “But Ben, why not skip all of this nonsense and implement this right into Rack?”. The reason I didn’t go right into Rack is…

1. Not every “Rack compatible” framework uses the Rack libraries. After digging through the rails internals I found that the RackRequest class extends AbstractRequest, which has nothing to do with Rack. Lastly, older versions of rails aren’t rack compatible.
2. I need to hook into the controller anyways with a before_filter
3. With my implementation you get the best of both worlds. I designed the AbstractAdapter to conform to the rack standards, and any framework specific implementation can subclass this and do it’s magic.

So what’s the big picture here? The big picture is that there is no reason Authlogic can’t be an authentication solution for virtually any ruby framework out there. Why reinvent the wheel for every framework?

What about framework X?

Since writing adapters for rails and merb was so simple, why not keep going? Here are a few frameworks I plan to write an adapter for:

1. Mack
2. Ramaze
3. Sinatra

If you are feeling generous and want to write an adapter for a framework other than rails or merb, please do so. Let me know about it and I will add it into the source.

Final thoughts

Authlogic loves you regardless of your framework

What if you could have authentication up and running in minutes without having to run a generator? All because it’s simple, like everything else in rails.

What if creating a user session could be as simple as…

UserSession.create(params[:user])

What if your user sessions controller could look just like your other controllers…

class UserSessionsController < ApplicationController
  def new
    @user_session = UserSession.new
  end

  def create
    @user_session = UserSession.new(params[:user_session])
    if @user_session.create
      redirect_to account_url
    else
      render :action => :new
    end
  end

  def destroy
    current_user_session.destroy
  end
end

Look familiar? If you didn’t know any better, you would think UserSession was an ActiveRecord model. I think that’s pretty cool. Why is that cool? Because it fits nicely into the RESTful development pattern and its a style we all know and love. Wouldn’t this be cool too…

<%= error_messages_for "user_session" %>
<% form_for @user_session do |f| %>
  <%= f.label :login %><br />
  <%= f.text_field :login %><br />
  <br />
  <%= f.label :password %><br />
  <%= f.password_field :password %><br />
  <br />
  <%= f.submit "Login" %>
<% end %>

Or what about persisting the session…

class ApplicationController
  helper_method :current_user_session, :current_user

  protected
    def current_user_session
      return @current_user_session if defined?(@current_user_session)
      @current_user_session = UserSession.find
    end

    def current_user
      return @current_user if defined?(@current_user)
      @current_user = current_user_session && current_user_session.user
    end
end

Authlogic makes this a reality.

Reclaim your UsersController

This is one of my favorite features that I think its pretty cool. It’s things like this that make a library great and let you know you are on the right track.

Just to clear up any confusion, Authlogic does not store the plain id in the session. It stores a token. This token changes with the password, this way stale sessions can not be persisted.

That being said..What if a user changes their password? You have to re-log them in with the new password, recreate the session, etc, pain in the ass. Or what if a user creates a new user account? You have to do the same thing. Here’s an even better one: what if a user is in the admin area and changes his own password? There might even be another place passwords can change. It shouldn’t matter, your code should be written in a way where you don’t have to remember to do this.

Instead of updating sessions all over the place, doesn’t it make sense to do this at a lower level? Like the User model? You’re saying “but Ben, models can’t mess around with sessions and cookies”. True…but Authlogic can, and you can access Authlogic just like a model. I know in most situations it’s not good practice to do this but I view this in the same class as sweepers, and feel like it actually is good practice here. User sessions are directly tied to users, they should be connected on the model level.

Fear not, because the acts_as_authentic method you call in your model takes care of this for you, by adding an after_create and after_update callback to automatically keep the session up to date. You don’t have to worry about it anymore. Don’t even think about it. Let your UsersController deal with users, not users AND sessions. ANYTIME the user changes his password in ANY way, his session will be updated.

Here is basically what is done…

class User < ActiveRecord::Base
  after_save :maintain_sessions!

  private
    def create_sessions!
      # create a new UserSession if they are not logged in
    end

    def maintain_sessions!
      # If we aren't logged in at all and the password was changed, go ahead and log the user in
      # If we are logged in and the password has change, update the sessions
    end
end

Obviously there is a little more to it than this, but hopefully this clarifies any confusion.

When things come together like this I think its a sign that you are doing something right. Put that in your pipe and smoke it!

Authlogic arouses me

That’s great, here are some resources:

• Repository: http://github.com/binarylogic/authlogic
• Documentation: http://authlogic.rubyforge.org/
• Tutorial: coming soon…