Rails Authentication: restful_authentication vs. authlogic

I've been spending a bit of time comparing Rails authentication mechanisms. The two main frameworks out there are the "restful-authentication" and "authlogic" libraries. The two provide the same general purpose functionality; users, sessions, cookies and emails.

The Restful authentication library is the current popular choice. I believe this is due to it being one of the first real options, as well as coverage in books like "Advanced Rails Recipes". The library is incredibly complex and opaque though. It relies heavily on generators and hidden code to produce its functionality. The install instructions are an exercise in command line arguments rather than code.

Authlogic has proven to be far simpler to digest. No real magic involved. One of the stated goals of the library is to be able to treat sessions as you would an active record model. You create a session, save a session and destroy a session like you would any other model. There are no generators you write the code yourself, and there is very little of it. The basic set of columns you need for a "User" show you that the library is well thought out with regards to security and usefulness. There are a number of columns though and this leads to a heavy initial copy & paste though. I felt a bit dirty having to do that, but I'll get over it. The rest of the code I have to write is transparent and understandable, a big plus. Oh, and do not assume that because "restful" isn't in the title that it lacks there. It doesn't, follow the tutorial and you'll produce a very restful solution.

You can probably tell from the above two paragraphs that I'm favoring Authlogic at this point. I definitely like the transparency and simplicity of it. To learn more about Authlogic you can follow along with the README in the main repository as well as the fantastic tutorial app. There are also a few extra tutorials on Ben Johnson's blog around password resets and openId.

Follow up to the AbstractHibernateDao

In my writing about the AbstractHibernateDao here I mention that you no longer need to extend HibernateDaoSupport class. You do lose one thing though. Your new AbstractHibernateDao based DAO will now throw HibernateExceptions, not Spring DataAccessExceptions. Now, to me, this isn't the end of the world. In a Hibernate 3.2+ world Hibernate does have a clear exception hierarchy. Not like the old days where there was just "HibernateException". That sucked.

If you do want your DAOs to throw Spring DataAccessExceptions there are two simple things to do.

1. Add the @Repository annotation to your DAO impl.
2. Add a PersistenceExceptionTranslationPostProcessor bean to your Spring setup.

What this does is tell Spring to wrap an interceptor around your DAO bean that handles the exception translation.

Looking at the UserDaoImpl from the past article...

@Repository
public class UserDaoImpl extends AbstractHibernateDao<User> implements UserDao {

    public UserDaoImpl(SessionFactory sessionFactory) {
        super(User.class, sessionFactory);
    }
    ...
}

Then in your Spring application context.xml you simply add one line...

Now, this pattern I present is somewhat old school. There is all this fancy component scanning stuff you can do with the Spring 2.5 XML namespaces. Honestly the amount of voodoo that goes on there freaks me out a bit. You can study that on your own if you'd like. A good place to start is here.

Amazon Elastic MapReduce

Amazon announced an Elastic MapReduce service in the AWS environment. This service combines S3, EC2 and the Hadoop MapReduce framework to provide a powerful distributed processing engine. This is pretty awesome stuff. Too bad I have no use for it right now, maybe I should make one up :P

Amazon Elastic MapReduce

Announcing Tiny VH

My Buddy Sean got angry about is.gd going down the other day, so he wrote his own URL shortening service. I'm gonna use it for everything, and you should too :P

Announcing Tiny VH

Announcing Fidgetr | >140 Characters

Announcing Fidgetr | >140 Characters

My friend Paul Kehrer over at the "> 140 Characters" blog has released his new WordPress plugin called Fidgetr. From his blog...

Fidgetr is a WordPress widget that displays the latest photos from your Flickr photostream in an attractive manner. It features support for its own themes along with very simple setup and good compatibility with various WordPress themes.

If you use WordPress and Flickr you should check it out.

YouTube - SCRUM in Under 10 Minutes (HD)

YouTube - SCRUM in Under 10 Minutes (HD)

Awesome!

git ready - pushing and pulling

git ready - pushing and pulling

A great overview of how git distribution works.

Simple Maven Archetype

I've been doing more and more with Maven lately. We're currently beginning the effort to migrate some of our stuff to Maven at work. A new feature of the archetype plugin was introduced a bit ago to generate java projects from a menu. This is done using mvn archetype:generate. This provides you with a (hideous) menu of options to begin a new project from a template.

The problem I have with this (besides the menu being hideous) is that Maven still defaults the compiler to use source/target settings for java 1.4. Every project I do that uses Java 1.5 needs to have the compiler config settings tweaked to allow the use of 1.5. It is really annoying, so I created my own simple archetype that I can use and uploaded it to github for easy access. http://github.com/raykrueger/simple-archetype/tree/master

This new archetype generates an empty project with compiler settings for 1.5, includes the dev.java.net maven repository and has dependencies for slf4j and junit.

I may move this archetype project in the future into a collection of archetypes. So I can have a simple java one, a webapp one, and whatever else I come up with. If I do move them, I'll update this blog :)