TrikeApps Blog

Per Request Cache for Rack

2011-11-16T00:00:00-08:00

Ever wanted a cache that is bound to the current request? Check out our new gem: Rack::PerRequestCache.

Installation & Usage


  gem install rack-per_request_cache

Have a look at the Readme to see how it's used!

Daemonize a script or worker in Rails 3

2011-05-12T00:00:00-07:00

A couple of gems allow the easy daemonisation of scripts / long running processes. But as soon as you need to include your Rails environment you might run into problems.

The problem

Take this script for example (which lives in script/ruote_worker.rb):


  require 'daemons'
  require File.expand_path(File.join(File.dirname(__FILE__),
  	'..', 'config', 'environment'))

  Daemons.run_proc('ruote_worker') do
    RuoteKit.run_worker(RuoteSetup.ruote_storage)
  end

Looks pretty straightforward - The daemons gem provides a run_proc method which daemonises the given block. But as soon as the ruote worker tries to write something to the log-file we get an IOError: closed stream exception.

Rails 3 wants the log file to itself

After some research it seems like Rails doesn't like it, when multiple processes have a handle on the log file(s). As the response in the linked question correctly points out, the solution is to instantiate a new logger... with one addition: If your process is using ActiveRecord, we need to re-assign the ActiveRecord.logger as well:


  require 'daemons'
  require File.expand_path(File.join(File.dirname(__FILE__),
  	'..', 'config', 'environment'))
  require 'ruote/part/smtp_participant'

  Daemons.run_proc('ruote_worker') do
    ruote_logger = ActiveSupport::BufferedLogger.new(
    	File.join(Rails.root, "log", "ruote_worker.log"))
    Rails.logger = ruote_logger
    ActiveRecord::Base.logger = ruote_logger
  
    RuoteKit.run_worker(RuoteSetup.ruote_storage)
  end

Our new TrikeApps office

2011-01-17T00:00:00-08:00

At the start of the year we moved into our new office. It's not far away from the old office... but way bigger!

Secure your forms with a simple Math Captcha

2010-12-20T00:00:00-08:00

As soon as your application has a form that's available to everyone, you WILL be spammed! So what can we do about it? Well, one option is to have all forms secured by authentication... OR we can use a captcha.

As always, there are a couple of plugins / gems out there that do the traditional image captcha (you know, the beautiful images with random text on it). The problem is though, some of them suck: Some look hideous (like recaptcha) and others require a lot of effort to set up (see simple captcha).

What are the options?

Basic Math! Asking a (really) simple mathematical question will prevent spam, because stupid bots are just to stupid to answer it :)

What do we need for a math captcha? Basically a generator to create a question and a two-way hashing algorithm to encode (and later decode) the question/answer. Here's the code (in a rails app, you want to place this class into the lib folder):


  require 'ezcrypto'

  class MathCaptcha
    CIPHER_KEY  = "secret key"
    CIPHER_SALT = "secret salt"

    attr_reader :a, :b, :operator

    def initialize
      @a        = (1..10).to_a.rand
      @b        = (1..10).to_a.rand
      @operator = [:+, :*].rand
    end

    def initialize_from(secret)
      yml = YAML.load(key.decrypt64(secret))
      @a, @b, @operator = yml[:a], yml[:b], yml[:operator]
    end

    def correct?(value)
      result == value.to_i
    end

    def encrypt
      key.encrypt64 to_yaml
    end

    def self.decrypt(secret)
      result = new
      result.initialize_from secret
      result
    end

    def question
      "#{@a} #{@operator.to_s} #{@b} = ?"
    end

  protected

    def to_yaml
      YAML::dump({
        :a        => @a,
        :b        => @b,
        :operator => @operator
      })
    end

  private

    def key
      EzCrypto::Key.with_password CIPHER_KEY, CIPHER_SALT
    end

    def result
      @a.send @operator, @b
    end
  end

The only interesting thing here is the code in the encrypt and decrypt methods. Basically, what we do is dump the relevant variables into a string using YAML and then encrypt/decrypt it using ezcrypto.

Integrating the captcha into the controller and view

Since our MathCaptcha already defines all the interface methods we need, the integration is straightforward. First the view (note how we use the encrypted question):


  / ... other form code
  %p
    = hidden_field_tag :captcha_secret, @captcha.encrypt
    = label_tag :captcha, @captcha.question
    = text_field_tag :captcha, ""
  %p
    = submit_tag "Send"

And the controller is easy as well. All we do is to intantiate the same captcha question with the use of the secret:


  require 'math_captcha'

  class ContactsController < ApplicationController

    def new
      @captcha = MathCaptcha.new
    end

    def create
      @captcha = MathCaptcha.decrypt(params[:captcha_secret])

      unless @captcha.correct?(params[:captcha])
        flash.now[:alert] = "Please make sure you answered the math question correct"
        render :new
      else
        ContactsMailer.question(contact).deliver

        flash[:notice] = "Thanks for your request. We will be in contact with you shortly"
        redirect_to root_path
      end
    end
  end

GData Spreadsheet Gem released

2010-09-01T00:00:00-07:00

Fresh from our office comes the GData Spreadsheet Gem. This is some logic we extracted from our PlanDeliver project, to map rows in a Google Spreadsheet to Ruby classes. Check out the github project page for detailed instructions.

Installation


  gem install gdata_spreadsheet

How to get a AuthSub session token for Google's GData

2010-08-19T00:00:00-07:00

In the last sprint for our truck routing application PlanDeliver we focused in large parts on making the app talk to a Google Spreadsheet. The idea is, that users can create/update orders in the Spreadsheet, which are then imported into the actual PlanDeliver interface. The spreadsheet on the other hand, receives live status updates of the orders, eg. about the allocation status.

As the integration library of choice we went for the excellent GData gem which wraps around a handful of Google APIs. Now, one of the more interesting things when talking to Google is Authentication (we discussed that before), fairly well explained in the GData on Rails tutorial. For those who don't want to read the whole tutorial: Basically, there are two methods available. The simple solution is to use username and password, the other option would be token based authentication.

Fail at first

Since we're pragmatic, we went with the easy solution first:


  client = GData::Client::Spreadsheets.new(:version => '3', :source => 'PlanDeliver')
  client.clientlogin('[google account email]', '[password]')

This worked fine when testing, but as soon as more people started using the feature, Google shut us down - apparently the number of authentications (per second) for one account is limited. So we started thinking about the token based option, named AuthSub. The good thing about AuthSub is, that you can create a 'session'-token which never expires! The bad thing is, that the whole token generation workflow is based on a request / response cycle which didn't work for us, because our GData integration is 100% backend...

Sinatra to the rescue

So we had to get a session token, but our app wasn't setup to get one. Of course, we could have added a controller to PlanDeliver to make it happen, but that would have created a lot of overhead: branching, merging, testing, deploying, reverting, ... So we decided to write up a very small Sinatra app that works as the endpoint for the Google authrorisation request and dumps the generated token somewhere. Here's all the code we need:


  [config.ru]

  require 'rubygems'
  require 'sinatra'

  root_dir = File.dirname(__FILE__)

  set :environment, ENV['RACK_ENV'].to_sym
  set :root, root_dir
  set :app_file, File.join(root_dir, 'authsub.rb')

  disable :run

  require 'authsub'
  run Sinatra::Application


  [authsub.rb]

  require 'rubygems'
  require 'sinatra'
  require 'gdata'

  get "/upgrade_token" do
    client = GData::Client::Spreadsheets.new(:version => '3', :source => 'PlanDeliver')
    client.authsub_token = params[:token]
    raise client.auth_handler.upgrade.inspect
  end

Start that up with thin and make it available through apache and you're ready to go!

Creating and using the session token

In order to actually use the mini-app, we have to use GData once again. This time we generate the URL which we have to visit (in a browser) to grant access:


  scope = 'https://spreadsheets.google.com/feeds/list'
  next_url = 'http://route/to/your/mini/app'
  secure = false
  session = true
  GData::Auth::AuthSub.get_url(next_url, scope, secure, session)

Open the generated URL in a browser, grant access (with the Google account of your choice) and watch the logs of the Sinatra app to find the session token. Then, instead of using clientlogin, we can use AuthSub when communicating with Google:


  client = GData::Client::Spreadsheets.new(:version => '3', :source => 'PlanDeliver')
  client.authsub_token = "[session token]"

Things on the side

Note that you need a different token for each Google service, eg. we had to repeat the process to get a token linked to the worksheet API (https://spreadsheets.google.com/feeds/worksheets).

The Sinatra app would be a prime candidate for a skinny daemon. Unfortunately the blog post came a day to late - but let us know when you publish (parts of) our code as a gem!

Simple authentication in Sinatra with Janrain Engage

2010-07-21T00:00:00-07:00

Everybody knows Sinatra and I'm sure that almost everybody has played with it. The simplicity of creating an app is just awesome. Unfortunately, as soon as the app gets a bit more complicated, and you need a more sophisticated feature - say authentication - you can't rely on all the nice plugins available for Rails (eg. devise or authlogic). So you end up either writing something yourself, or using an external solution.

So, inspired by this blog post we ended up with a fully functional (and good looking) authentication solution with minimal effort (check out the full source).

Setup

Sign up for Janrain Engage first and walk through the wizard that sets up your account. Fortunately the basic version is free (and that's all you really need for an in-house app). The only thing at this point that links Engage to your app, is the token URL you have to specify in the wizard. We skip over all the other configuration options here, because they aren't necessary to make the sign-in work.

Authentication in less than 30 lines of ruby code

In our code, we need an endpoint for Engage. This should (of course) map to the token URL specified before, so with eg. http://example.com/signed-in you should end up with something like:


  post "/signed-in" do
    if authenticate(params[:token])
      redirect "/"
    else
      redirect "/sign-in"
    end
  end

Now to the interesting part, the authenticate helper:


  def authenticate(token)
    response = JSON.parse(
      RestClient.post("https://rpxnow.com/api/v2/auth_info",
        :token => token,
        :apiKey => "[your api key]",
        :format => "json",
        :extended => "true"
      )
    )

    if response["stat"] == "ok"
      session["user"] = response["profile"]["identifier"]
      return true
    end

    return false
  end

We pass in the received token and use the beautiful rest client gem to authenticate the user with Engage. The result is a (across all providers) standardised JSON response. In our case, we just store the identifier in the session and the user is authenticated! Now, to make our life easier, we add a couple more helper methods:


  helpers do
    def logged_in?
      !!current_user
    end

    def current_user
      User.first :identifier => session["user"]
    end
  end

The end result

Integrating Google Federated Login with your Rails app

2010-07-20T00:00:00-07:00

When making one of your apps available on the google apps marketplace and you're not aiming for the full integration, pretty much all you have to (or at least should) do, is to allow a user to sign-in to your app using his google account. This sounds easier than it actually is, because Google's OpenID - called Google Federated Login - is not really standard OpenID. Otherwise, using one of the existing plugins for authlogic (our authentication framework of choice) would have done the trick.

Our way to glory

We had a look at a couple possible solutions, including writing our own authentication library, or using a third-party solution. But that was either to complex, or it didn't exactly provide what we needed. So we ended up changing an existing plugins and our good old friend Dr Monkey Patch.

Authlogic trickery

The first thing to notice is, that if you use a fairly recent version of the open_id_authentication plugin (which is used by the authlogic-openid plugin and itself uses rack-openid and ruby-openid), binary logic's version ain't working - but this fork is! And, authlogic's auto_register feature didn't work for us at all. In theory, this should create a user-record whenever a non-existing person authenticates, but in our case, it led to infinite loops, because the user validated the session, which then tried to create a user, which validated the session... so we ended up writing our own auto-register method (more about that later).

Another issue was, that Google Federated Login uses Attribute Exchange (AX) with OpenID instead of the more common Simple Registration Extension (SReg). By specifying required fields in the acts_as_authentic definition within your user model, you can force the use of AX attributes in the request:


  acts_as_authentic do |c|
    c.logged_in_timeout = 1.hour
    c.openid_required_fields = [
      'http://axschema.org/contact/email',    # Email
      'http://axschema.org/namePerson/first', # First name
      'http://axschema.org/namePerson/last'   # Last name
    ]
  end

This makes Google happy, but in order to be able to extract the users email and name from the response, we had to patch the open_id_authentication plugin (our fork). By default the plugin parses the response as SReg, but we needed AX, so the only thing we had to change was


  OpenID::SReg::Response.from_success_response(response)


  OpenID::AX::FetchResponse.from_success_response(response)

These two rather small changes will allow your users to authenticate through Google.

Auto-Register new users

As mentioned earlier, authlogics built-in auto-register function caused some headaches. But we needed that feature for a seamless user experience, so we had to implement it ourselves. The easy part was to write the code that creates a user:


  class User
    def self.register_with_openid(openid_identifier, openid_ax_response)
      login = openid_ax_response['http://axschema.org/contact/email'].to_s

      user = User.find_by_login(login)
      user ||= User.new(:login => login)

      user.openid_identifier = openid_identifier
      user.name = [
        openid_ax_response['http://axschema.org/namePerson/first'],
        openid_ax_response['http://axschema.org/namePerson/last']
      ].select(&:present?).join(' ')

      user.save_without_session_maintenance # otherwise we cause havok!
    end
  end

Note the last line, which makes sure that we don't care about an associated session - would we just call save we would get an infinite loop as well! After taking care of that, we can go ahead and monkey-patch the open_id_authentication plugin to register a user after successful authentication:

  def complete_open_id_authentication_with_registration(&block)
    complete_open_id_authentication_without_registration do |result, openid_identifier, registration|
      User.register_with_openid(openid_identifier, registration) unless result.unsuccessful?
      yield result, openid_identifier, registration
    end
  end
  alias_method_chain :complete_open_id_authentication, :registration

Make rails render different views for multiple sites

2010-06-07T00:00:00-07:00

At Trike, we have an app that uses the same code (and instance!) for several clients. The clients need the same kind of app, the differences are with the styling and (sometimes) the content.

Our first solution

Applying different styles is dead easy! Showing different text (or whatever) is easy as well and we came up with a workable solution (put this in application_helper.rb):


  def render_for_client(partial, options = {})
    return "" unless
      File.exist?(File.join(RAILS_ROOT, "app", "views", current_client.name, "_#{partial}.html.erb"))

    render "#{current_client.name}/#{partial}", options
  end

This worked quite well for a number of reasons:

We identified the parts of the app that are client-specific
We didn't have to worry about partials that are only used with one client (return "")
We didn't have to touch the rails internals

Nice, but not good enough

In short: It wasn't perfect. In particular, it happened that we rendered a 'regular' (shared) partial when we shouldn't. It was just too easy to call the default render method...

In fact - the more we thought about it - we realised that it should be the other way around: Rendering a client specific template should be the default!

So we went ahead and discussed ways to overwrite / monkeypatch the ActionView::Base#render method. After a quick spike, this turned out to become extremely tricky, very fast - mainly because ActionView::Base#render is used in almost all controllers and mailers. Actually, it handles all kinds of situations: from rendering partials and templates to handling layouts.

Rendering partials - Our Way

To solve our problem, we had to dig deeper rails internals. And after a while we found a method that we could adapt to solve our problem: ActionView::Base#render_partial. So without further talk - this is the module that we ended up including in ActionView::Base:


  module RenderSafetyNet
    def self.included(base)
      base.class_eval do
        include InstanceMethods
        alias_method_chain :render_partial, :client
      end
    end

    module InstanceMethods
      def render_partial_with_client(options = {})
        if options[:shared_template] || (options[:locals] && options[:locals].delete(:shared_template))
          render_partial_without_client(options)
        else
          partial_path = options[:partial]

          if (String === partial_path || Symbol === partial_path) && !options.has_key?(:collection)
            begin
              options[:partial] = prefix_partial_path(partial_path)
              render_partial_without_client(options)
            rescue ActionView::MissingTemplate => e
              message = e.message + <<-MSG

  We were looking for a client specific template.
  If you really wanted to render a shared template, please specify the option :shared_template => true
              MSG
              raise e.exception(message)
            end
          else
            render_partial_without_client(options)
          end
        end
      end

      def prefix_partial_path(path)
        "#{client_identifier}/#{path}"
      end
    end
  end

With the new module, we are able to use render for both situations, rendering shared and client specific templates. We also changed what kind of template is called by default. So, if you want to render a client specific template you just use render the way it was intended:

  render "about"

This will then map to the [client_name]/about template. On the other hand, if you want to render a regular file, you are forced to specify an extra option:


  render "login", :shared_template => true

Conclusion

If you look at it from a coders perspective, we ended up with a lot more code - with basically the exact same functionality. So why did we do it? Because we have 'tiny little monkey brains' (@mfallshaw)! This code prevents us from making the simple mistake (again) by including client specific, and maybe even confidential, information on the wrong site.

So yes, we have more code than before - but we took responsibility (or debt) away from our brains and made sure that we're doing the right things (in the future).

Thinking Sphinx with custom joins

2010-05-07T00:00:00-07:00

Today we tried to add an attribute to our Sphinx index definition that uses an association with GROUP BY and HAVING. This was our first attempt:


  # association definition
  has_many :regularly_ordered_by, :class_name => "Order",
    :finder_sql => 'SELECT DISTINCT(orders.user_id)' +
      'FROM orders LEFT OUTER JOIN line_items ON (orders.id = line_items.order_id)' +
      'WHERE line_items.product_id = #{id} AND orders.user_id IS NOT NULL' +
      'GROUP BY orders.user_id HAVING COUNT(*) > 1'

  # index definition
  define_index do
    ...

    has regularly_ordered_by(:user_id), :as => :regular_for_users

    ...
  end

Unfortunately, TS generates a huge SQL query to generate the index and uses a GROUP BY clause by default, so it ignores any of the slightly advanced SQL features we needed. After a couple hours experimenting we came up with a TS index query, that worked. But this solution was rather ugly, because we couldn't rely on TS to generate the config for us anymore.

So because we're developers, we decided to fork and extend TS - you can get a copy at Tricycle's fork of TS. With the extension you can specify any SQL that will be appended after the generated joins. In the end, our solution looked something like this:


  # association definition
  # no association needed

  # index definition
  define_index do
    ...

    has "`temp_regularly_ordered_by`.user_ids", :as => :regular_for_users, :type => :multi

    from <<-SQL
LEFT OUTER JOIN (
  SELECT product_id, GROUP_CONCAT(DISTINCT user_id) user_ids FROM
    (
      SELECT `products`.`id` product_id, `orders`.user_id FROM `products`
        LEFT OUTER JOIN `line_items`
          ON (`products`.`id` = `line_items`.`product_id`)
        LEFT OUTER JOIN `orders`
          ON (`orders`.`id` = `line_items`.`order_id` AND `orders`.user_id IS NOT NULL)
      GROUP BY `products`.id, `orders`.user_id HAVING COUNT(`orders`.id) > 1
      ORDER BY NULL
    ) AS regular_products
  WHERE USER_ID IS NOT NULL
  GROUP BY product_id
) AS `temp_regularly_ordered_by` ON (`temp_regularly_ordered_by`.product_id = `products`.id)
      SQL

    ...
  end

Calculating counts for all array items

2010-05-07T00:00:00-07:00

Ever wondered how often a specific item occurs in an Array?


  >> [1, 2, 1, 3, 4, 2, 1, 1, 3, 5, 5].grep(3).size
  => 2

Now, if we take that a step further, we can calculate the counts for all elements:


  >> list = [1, 2, 1, 3, 4, 2, 1, 1, 3, 5, 5]
  => [1, 2, 1, 3, 4, 2, 1, 1, 3, 5, 5]
  >> list.uniq.inject({}) { |res, item| res.merge(item => list.grep(item).size) }
  => {5=>2, 1=>4, 2=>2, 3=>2, 4=>1}

The Government ...

2010-05-04T00:00:00-07:00

Announcing Rack::ChromeFrame

2010-04-30T00:00:00-07:00

Google Chrome Frame is a great way to enable modern browser features without forcing the user to upgrade or switch web browser. Once installed it is activated by either including a meta tag in the head of each page or by setting a header with the same name and value in responses from the web server. Specifically:

X-UA-Compatible: chrome=1

The inclusion of the meta tag or setting the header is a good candidate for Rack middleware as it doesn’t need to interact with the application at all. A quick search revealed some existing work by Luigi Montanez of sunlightlabs. This implementation injects the meta tag into html responses. Favouring setting the header I created a very simple rack middleware and bundled it up as Gem. For building and releasing the gem I used Jeweler, which made the process totally painless:

% jeweler rack-chromeframe

Edit code…

% rake build
% gem push pkg/rack-chromeframe-1.0.0.gem

The gem is called rack-chromeframe and the code is on GitHub.

Using the Gem

Install

gem install rack-chromeframe

Rails

To use Rack::ChromeFrame in a Rails project:

Add the following gem dependency you your config/environment.rb:

config.gem 'rack-chromeframe', :lib => 'rack/chrome_frame'

Then use the middleware (also in config/environment.rb):

config.middleware.use "Rack::ChromeFrame"

Rack

To use Rack::ChromeFrame in a Rack application (such as Sinatra) add the following to your app:

gem 'rack-chromeframe'
require 'rack/chromeframe'

use Rack::ChromeFrame,

run app

That’s it! Now all your responses will have the X-UA-Compatible header set to enable Chrome Frame.

Blogwarming Party

2010-04-28T00:00:00-07:00

G'Day.

We are awesome!

Having said that, we are also a boutique development shop specialising in web applications written in Ruby (look here, here or here).

We'll be sharing all the challenging (or otherwise interesting) stuff that we stumble upon during our day to day work on this blog... Enjoy!