About

Speed up work on your development environment by “cheating” the passwords. Read on for details…

Details

Tired of managing passwords in a development environment? Developing an application that ties into a central authentication system used by several other applications (such as with Rack::Auth::Kerberos and/or Rack::Auth::Cookie?)

In cases like this, it’s handy to be able to “cheat” in a development environment and just log in as any username you like, immediately.

Rack::Auth::Cheat was writtten with this situation in mind. It is available on github:
http://github.com/charlieok/rack-auth-cheat

…and can be installed from gemcutter:
[sudo] gem install rack-auth-cheat

Add this to the middleware stack of each of your applications, or near the root if they’re organized in a ‘rack graph’ (in the development environment, not across all your environments!), and tell it what params to watch for usernames and passwords. Now you can sign in as any user by just entering the username again in the password field.

Rack::Auth::Cheat fits into a set of middlewares I’ve been working on with Dan Berger which are intended to be mixed and matched according to your tastes. The thing they all have in common is that they use, and set, a common group of environment variables for applications to use:

env[‘AUTH_USER’] = the username behind the current request, if authentication was successful
env[‘AUTH_FAIL’] = the reason the current request failed authentication, if in fact it did fail

If AUTH_USER is set, the request was successfully authenticated. If AUTH_FAIL is set, the request failed to authenticate and applications should show that failure message to the user. If one is already set when #call is invoked, no action will be taken (this is what makes this middleware “stackable”). If neither is set by the time a request reaches a “leaf” application, the application should consider the request anonymous.

There are other environment variables this collection of authenitcation middleware uses, but AUTH_USER and AUTH_FAIL are the most important ones for applications and other middleware to pay attention to.

To extend this set of middleware to do a new kind of authentication (say, facebook, openid etc) simply write another separate middleware class that treats these environment variables the same way. That is, passing through requests when AUTH_USER and AUTH_FAIL are set, ignoring requests that don’t apply to their particular method, or setting the appropriate values if they do. Applications can then decide the order in which to try different methods by simply ordering those methods accordingly in the middleware stack.

Usage

Put this in your config/environments/development.rb file for a rails application, or some equivalent place for some other type of application:

config.middleware.insert_before “Rack::Auth::Kerberos”, “Rack::Auth::Cheat”, “username”, “password”

Here I’m telling it to place Rack::Auth::Cheat in front of Rack::Auth::Kerberos (my normal, not cheating auth method) in my middleware stack, and to watch the “username” and “password” params for usernames and passwords.