Toluu

Rail Spikes

Announcing follow cost: Is that Twitter celebrity worth the pain?October 13 2008

Have you ever wondered if it was worth following someone on Twitter?

Now you have another tool to help you make that decision: follow cost. Give follow cost a Twitter user name and it will calculate how often they tweet on average. As a yard stick, follow cost uses the milliscoble, defined as 1/1000th of the average daily Twitter output of Robert Scoble. As an example, here’s my follow cost (currently, 133 milliscobles).

There’s even a bookmarklet you can use when viewing a Twitter profile.

We’ve got some neat features planned for the future, but to do them, we need better hosting. So we’re looking for a sponsor. Contact me if you’re interested.

Building follow cost

I built follow cost with my friend (and Harvest developer) Barry Hess. The idea for a service “to tell you ho

Side projects and experiments: expanding the reach of page cachingSeptember 29 2008

One of the many benefits of side projects is that you get to try out new things. In my job I can’t screw around too much—I’ve got a site to run. But with side projects, I can play with new APIs and try out ideas. Lately, Twistr has been my playground.

Twistr. Twitter + Flickr = LOLs?

In the case of Twistr, shared hosting is the mother of invention. To give Twistr “teh snappy” on crappy shared hosting, I wanted to use page caching. Page caching is the simplest and fastest Rails caching mechanism—it writes the result of a request to an HTML file which is served by the web browser for subsequent requests. Rails is bypassed entirely.

Page caching: First request

Page caching: subsequent requests

Is your Rails application safe?September 22 2008

Rails provides many great security features. It’s design can also create significant security holes. In the case of ActiveRecord’s mass assignment vulnerability, the security issues are more servere and widespread than many of us recognize.

Nearly every open source Rails application I’ve seen is vulnerable, and most closed source ones as well. There’s some great solutions for protecting your application from attack, but first, the problem:

The Problem

By default ActiveRecord allows visitors access to any writer method, that is, any method ending with an equal sign. This comes courtesy of the ActiveRecord::Base#attributes= method, which is used internally by the main methods that handle creating and updating records, including new(), create(), and update_attributes().

The way most applications are designed means that whatever data a visitor sends to the server will likely find its way through the attributes=() method, and if not protected, ActiveRecord will happily update the records based on what was sent. In less technical terms: ActiveRecord is insecure by default.

As an example, let’s look at a request against vulnerable code:

1 2 3 # The request $ curl -X PUT -d "order[price_in_cents]=0" example.com/orders/225 app/models/order.rb 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 class Order < ActiveRecord::Base # Ta

Testing SSL in RailsSeptember 12 2008

Here’s a quick tip for how to test that your application is using SSL correctly.

Enabling SSL in tests

You can turn SSL on in functional tests like this:

@request.env['HTTPS'] = 'on'

I have this turned on in my setup method and then override it for tests that don’t use SSL. To turn SSL off, use this:

@request.env['HTTPS'] = nil

(Via snippets)

Testing for SSL redirect

To test and see if you users will get redirected to SSL for particular actions, you can write a test like this. First, it turns off SSL. Then it makes a request to a method that should require SSL, and asserts that the request is redirected to the same URL, but using the https protocol.

1 2 3 4 5 6 def test_get_new_with_http_should_redirect_to_ssl @request.env['HTTPS'] = nil get :new assert_redirected_to "https://" + @request.host + @request.request

How to fix your Rails helpersAugust 22 2008

Many Rails applications have this basic structure in their helpers folder:

1 2 3 4 5 6 7 8 9 10 11 application_helper.rb accounts_helper.rb audits_helper.rb comments_helper.rb images_helper.rb orders_helper.rb posts_helper.rb sessions_helper.rb users_helper.rb ... etc.

The most important file, as we all know, is application_helper.rb, because this is where code goes to die. It’s often a few hundred lines of randomly added, unrelated methods. This is a confusing, scary place for methods to be. Here’s a few tips for rescuing them:

What’s that noise?

Most projects use script/generate to make their controllers. This leaves a ton of empty helper files. Remove them to better focus on the task at hand:

1 2 hg remove accounts_helper.rb audits_helper.rb images_helper.rb ...

Usually this will prune the list down to two or three files.

Farewell, application_helper.rb

The easiest way to clean up the ApplicationHelper module is to remove it. This is a great way to ensure methods don’t stay there, or get inserted in the future. But, if they don’t belong in ApplicationHelper, where’s the best place for them?

1. Remove fake helpers

Helpers are markup generators. If they’re not involved in generating markup, they’re not helpers and can be pushed into a model:

helpers/application_helper.rb 1 2 3 4 5 6 module ApplicationHelper def