A loyal data retriever for Rails development databases

Nov 5th, 2012

We work with a wide range of database systems at Littlelines. On any given day, we can jump
back and forth between PostgreSQL, MySQL, or MongoDB databases, each with its own specialized
application (or lack thereof) to get a quick look at our data. Coupled with different credential
sets for each of our Rails applications, this can be a cumbersome experience, especially when we
just need a quick overview of our database structure or records.

Features

Web-based, database “agnostic” client, allowing the same interface and look and feel across entirely different database systems

PostgreSQL, MongoDB, MySQL, and SQLite support with others on the way

Quick, friendly, and customizable install with a single copy/paste into your shell

As developers, we automate away as much as possible, and Labrador is no exception to that.
Labrador is a Rails app itself, and integrates with pow for a zero configuration setup,
Rails application discovery, and automatic database connections. It lets us do neat things
like load rubyrags.labrador.dev in a browser and have an immediate look at our local Ruby Rags
development database without having to tell Labrador anything about the application’s database
credentials, database system, or app location. It is a great time saver for debugging, schema
reference, and quick database tweaks.

Security

Distributing a Rails app in this manner, to be run locally across many different installs,
requires a few security requirements outside of the traditional Rails application setup.
Most importantly, Labrador uses cookie-based session storage. Typically, a Rails app uses a
random string for signing cookies that is checked into version control. Since Labrador is
distributed for many to use, hard-coding a secret token for session storage would leave the
application’s authenticated sessions vulnerable since an attacker would know how to sign his/her
own cookie and potentially gain unauthorized access to a developer’s local databases.
Labrador prevents this scenario by looking for a secret_token.yml file when the application
starts up. If it does not exist, it writes a random secret token to this file and references it
upon subsequent application startups.

Labrador will also refuse to allow database connections unless it is provided
HTTP Basic Authentication credentials, which must be entered as part of the application’s
install process.

Coming Soon

Labrador has some exciting features in the pipeline and already serves us well for our
day to day debugging needs. Install Labrador or checkout the codebase, and be sure to stayed tuned for new features: