How to Switch Your Cedar Heroku App from Webrick to Thin

Received an en email today from Cody K on my use of Webrick in production for Lean Domain Search:

Hey Matt,

Lean Domain Search is really neat – thanks for making it available.

Just wanted to let you know that it’s a really bad idea to run Ruby web apps with Webrick in production – you should be using something like nginx and either Unicorn or Passenger. Those are battle-hardened and production-ready, whereas Webrick’s sole purpose is for development environments, and, as such, is not heavily tested (if at all) for security issues and whatnot.

Just a friendly heads up. :) Thanks again.

Heroku’s Rails 3 docs are also pretty clear on this and I remember reading it during my initial upgrade, but never got around to actually doing it.

Thin is a recommended app server over Webrick (the default for rails).

Switching to Thin is pretty easy:

1. Add gem 'thin' to your Gemfile:

I added it to the production group because I want to keep using Webrick in development for now.

2. Make sure that you run bundle install to update your Gemfile otherwise you’ll receive a warning like this when you push to Heroku:

You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
You have added to the Gemfile:
* thin

3. Add a Procfile to your root directory to instruct Heroku to use Thin instead of Webrick:

4. Commit and push your updated app to Heroku.

If all went well, you should see something like this in your logs:

2012-01-18T12:44:33+00:00 app[web.1]: >> Using rack adapter
2012-01-18T12:44:33+00:00 app[web.1]: >> Thin web server (v1.3.1 codename Triple Espresso)
2012-01-18T12:44:33+00:00 app[web.1]: >> Listening on 0.0.0.0:38951, CTRL+C to stop
2012-01-18T12:44:33+00:00 app[web.1]: >> Maximum connections set to 1024
2012-01-18T12:44:34+00:00 heroku[web.1]: State changed from starting to up

Too easy.

One thing confused me though: How did Cody know that I was using Webrick? I emailed him and asked.

His response:

I mistakenly typed some bogus characters in at the end of my address bar while I was on your site…something like this: http://www.leandomainsearch.com/search?q=up^jf

Sure enough, Webrick fails loudly when the URL includes a caret:

Touché.

Integrating Big Huge Thesaurus’s API into Lean Domain Search

Big Huge Thesaurus by John Watson provides an excellent thesaurus API that can be quickly integrated into any app.

The first step is to sign up for an API key which takes less than a minute. The API is free up to 10,000 requests per day and cheap if you need more than that.

After you fill out the required information the site will generate an API key for you which you can use to access the API.

Here’s a simplified example of how I’m using it with in Lean Domain Search via jQuery:

$.ajax({
  url : "http://words.bighugelabs.com/api/2/youapikey/" + word + "/json?callback=?", 
  dataType : 'json',
  complete : function(jqXHR, textStatus) {
    if (textStatus == 'parsererror') {
      // Did not find any synonyms
    }
  },
  success : function(data) {
    // Found synonyms
    alert(data);
  }
});

(View Gist)

Here’s an example of the returned JSON data for the word “open”:

Note that the results are broken up by part of speech (noun, adjective, etc) and are further broken up into groups (“ant” for antonyms, “rel” for related terms, “sim” for similar terms, “syn” for synonyms).

All in all it took about two hours to integrate the Big Huge Thesaurus API into Lean Domain Search and only because I added some extra functionality (sorting and filtering the synonym list, tracking what % of the searches are discovered via the synonym list, etc).

Here’s what Lean Domain Search looks like now — note the synonym list in the right column:

Click here to check out the results for “open”.

How to Automatically Back Up your Heroku site to Dropbox

This post will explain how you can configure your machine to automatically back up your Heroku site each night and save the bundle to your Dropbox folder.

At a high level, here’s how it works:

1) Each night at 11pm, a cron job executes a Ruby script that tells Heroku to create a bundle of your site

2) At midnight, the same script downloads the bundle and moves it to your backup folder, which can either be a local directory or your Dropbox folder

Creating and Downloading a Heroku Bundle

The following Ruby script does one of things depending on whether a bundle exists or not.

If a bundle does not exist, the script tells Heroku to create one. If one does exist, the script will download it and move it to your backup location.

Creating a bundle can take some time depending on how large your site is, so you should wait a while before running the script again to download it, which is why we’re going to tell the cron job to wait an hour before downloading it.

The script takes two arguments:

  1. The full path to your local Heroku application
  2. The full path of your backup folder

For example, here’s how I would have the script back up jMockups:

ruby heroku_backup.rb /Users/Matt/jmockups /Users/Matt/Dropbox/Backups/

This tells the script that my app is located in /Users/Matt/jmockups and I want to save the bundle to /Users/Matt/Dropbox/Backups/.

The code:

[ruby]

APP_DIR = ARGV[0]
BACKUP_DIR = ARGV[1]

# run a command from your app’s root directory
def cmd(str)
return `cd #{APP_DIR}; #{str}`.sub(10.chr, ”)
end

puts(‘* Determining bundle status…’)
status = cmd(‘heroku bundles’)

unless status.index("has no bundles.").nil?
# No bundle currently exists, so have Heroku create one
puts(‘*** Capturing bundle because none exist…’)
capture = cmd(‘heroku bundles:capture’)
else

bundle_name = status.split.first

unless status.index(‘complete’).nil?
puts(‘*** Bundle was captured successfully’)
puts(‘* Downloading bundle…’)

download = cmd(‘heroku bundles:download’)

puts("*** Moving #{bundle_name} to backup location…")
filename = download.split.last
newname = "#{bundle_name} (#{Time.now.strftime(‘%Y-%m-%d %H%M%S’)}).tar.gz"

move = `mv #{APP_DIR}/#{filename} "#{BACKUP_DIR}/#{newname}"`

puts(‘*** Destroying remote bundle…’)
destroy = cmd("heroku bundles:destroy #{bundle_name}")

puts(‘* Done’)

end

unless status.index(‘capturing’).nil?
puts(‘*** Still capturing. Try again in a bit…’)
end

end
[/ruby]

Automating the Backup Process with Cron

Once you’re convinced this works as advertised, you can automate this process with cron:

  1. Delete any existing bundles using the heroku bundles:destroy command. If you don’t the script will download the bundle at 11pm and capture it at midnight, which will work, but is probably opposite of what you intend
  2. At the command line, type crontab -e
  3. Add the following line to the crontab file, replacing the paths with your own:

0 0,23 * * * /usr/bin/ruby /Users/Matt/Documents/Backups/heroku_backup.rb /Users/Matt/jmockups /Users/Matt/Dropbox/Backups

This basically says “When the minute value of the current time is 0 and the hour is 0 or 23 (midnight or 11pm), use Ruby to run heroku_backup.rb with these parameters.

With automatic daily backups, you can rest easier by knowing that if your site gets obliterated things will suck a little bit less. And if you have additional sites, you can simply add multiple lines to the crontab file with the information for your other apps.

Plus, it beats paying $20/month for unlimited bundles with the Heroku addon. :)

Revolution

(I’m going to start going over the major projects I’ve worked on over the years.)

This project, dubbed Revolution, was my first major programming endeavor. I worked on it heavily in late 1998 and distinctly remember sending it to my friends in middle school and watching with pride as they used it to scroll massive amounts of text in random AOL chat rooms.

This was the reason I got into programming in the first place. My friend Jake sent me an AOL prog (program) and curious, I set out to learn how to build one.

The code is absolutely terrible and the only thing uglier is the design. It was a start.

Here’s some screen shots:

And here’s the menu hierarchy which shows all the exciting features:

I almost forgot about this program until I was going through some old 3.5″ disks and came upon it. I’m glad I did… I haven’t seen the words “Lagger” or “Punter” or “Fader” in many years.

Gotta love it.

Why to Set a Time Limit on Password Reset Emails

You know those password reset links that are sent to you get when you forget your password? Well, some of them set a limit on how long you can use it before the link stops working. For the life of me, I couldn’t figure out why sites did this. Who cares how long it takes me to get around to resetting my password? Why not just make the same link work every time a person wants to reset his or her password?

So, I coded up a registration and password reset system for Domain Pigeon without setting a time limit on reset password links.

Last night, somewhat randomly, it hit me why this is a bad idea. It’s so obvious now that I don’t know why I didn’t think of it sooner.

If you reset your password in a public place, such as a library computer, the reset password URL will probably be stored in the browser navigation history. The next person who uses the computer might accidentally come across the “www.whatever.com/reset/…” URL and click it to see what happens. Surprise: it still works.

So how do you prevent this? You guessed it: a time limit.

Here’s how I implemented it for Domain Pigeon. When the customer requests a password reset email, store the time they requested it and then, to generate the URL, use a hash of the user’s email concatenated with the time they requested it. This’ll ensure that the URL is unique based on that specific request (aka a salt).

Then, when the customer clicks the link to reset his password, compare the current time to the time the link was sent and if it’s less than a specific amount of time, allow him to change his password. In pseudocode, this looks something like:

if hash(user.email + user.forgot_sent_at) = params[:hash] and user.forgot_sent_at + 2.hours > Time.now then
... yada yada yada
end

[Update: Note that the has function used here is a SHA-1 hash of the input concatenated with a secret key, so that the final product here = SHA(user.email + user.forgot_sent_at + long_random_string). Thank you to Artem for pointing out it needed to be clarified]

Lastly, after the password is changed, reset the stored time. That will prevent someone from changing the password twice using the same reset password link.

The only flaw I see with this method is for the person who clicks the link to reset his password and abandons it, because that’ll allow someone else to access the page and reset his password. Fortunately, this should be rare enough that it’s not a major problem. For extra security, set the time limit to five or ten minutes. After all, how many people request a reset password link and don’t access it within the next few minutes? For the few that do, they probably won’t mind the small annoyance in return for the extra security.

If anyone has any thoughts on this method or password reset algorithms in particular, please let me know.

Macs: Productivity made Easy

Day #3 of the Macbook…

I began working today with the intention of integrating a test Heroku site with Paypal’s Instant Notification System. Didn’t get there quite yet, but I’m getting there. Here’s a few things I worked on this evening:

Modifying the Terminal Prompt

Every line had been displaying “matthew-mazurs-macbook: Matt $” or something long and annoying like that, so I looked into how to change it. Some helpful individual on #rubyonrails told me to look up PS1 and surely enough, changing it is pretty easy. This site teaches you how to change it, though this method only works for the current terminal. When you reload the terminal the name reverts to its previous state. To change it permantely, you have to close down termal and edit /etc/bashrc in some text editor. Change the PS1 name to whatever you want and it’ll be changed permantently for future terminal windows. There’s probably an easier way to do this but hey, it worked.

Using VI

As nerdy readers have probably realized by now, I suck at the command prompt. I regret not taking more opportunities during my college compsci classes to gain more experience with it. Anyway, this tutorial is a pretty good introduction to what you need to know in order to navigate vi.

Ruby Gems

Up until this point in my app’s development I haven’t had to use any gems so I was pretty lost when I read I should install a Paypal gem to interact with Paypal’s Instant Payment Notification system. For the unenlightened, IPN is an alert that Paypal sends to your site when someone has made a purchase. You can use this notification to enable a user’s account, for example. Thankfully, rubygems.org offers an excellent tutorial which quickly brought me up to speed. I worked my way through their progressbar example, which as stupid as it is, was a nice thing to get working.

Fortunately, while developing ALL IN Expert (more to come on that — I promise), I spent a lot of time learning how to do IPN with PHP. Things are slightly different now, but the prior experience is helpful.