Wow.

Rails is a powerful framework, and many common things are made easy. For a professional website, using SSL judiciously is very important, particularly in an era of social networking and instinctive trust of sites with personally identifiable information (eg, phone numbers). But Rails does not make it easy to use SSL. So, in an effort to save someone else a few days of internet searching, here are the four steps needed to use SSL with Rails on your site. I am not going to discuss how to get the certificates and/or set up Apache to use SSL (see reference below for a reasonably good article on that topic). No, I discuss here only the comparatively straightforward task of redirecting requests to HTTPS and/or designating that forms must be sent via SSL. This is not as simple as ‘use the ssl_requirement gem’. Not by a long shot.

What we want to do

SSL assures information privacy. As data flows back and forth between the server and the client, it is passed between many intermediating servers, any of which might not be friendly and store, inspect, and misuse the information. So it’s important to encrypt anything which might be misused. However, we don’t want to encrypt everything, because encryption and decryption takes a fair amount of processing overhead, which both slows things down and adds unnecessary load to the server. It’s important to remember that the information flows both directions: it flows out to be displayed on screens, and then the end user may type data into forms and information flows back in. So the goal here is to selectively decide when to use encryption (via HTTPS) and when to use the lighter-weight, unencrypted HTTP. There’s one more wrinkle to this. As I mentioned, I’m not going to discuss how to set up your servers and get certificates and so on. There are a few reasons for this, but one of them is that setting all of that up sucks hard. Like, hours of frustrating tweaking of inscrutable directives, with limited ability to debug, exactly the sort of irritating development stuff we went to Ruby and Rails to avoid. Which is to say, you don’t want to use SSL except when you absolutely need to, and you definitely don’t want to have to set it up every time a new developer joins your team or your box fails and you discover that you’ve misconfigured Time Machine so it isn’t backing up your /etc directory — sorry. I digress. Point being, we don’t want to use SSL in development.

Step 1: Outbound information

Ok, this looks easy at first blush. Rails knows the protocol that the arriving request used (in this case, either “http://” or “https://”). Well, it will if the proxy server was configured correctly and sets X-Forwarded-Proto in the request. But again, I’m not talking about that here. Since Rails knows the protocol, it knows what environment we’re running in, and it certainly knows how to redirect requests, so there are many articles which suggest that all you need to do is redirect to or from the right protocol. However, the important trick here is that you can’t simply redirect :protocol => "https://", because that will lose any parameters in the request. So you need to be careful to include all the parameters in your request. Without further ado, a pair of filters and a helper. I add these to my ApplicationController:

  # Usage: before_filter :require_ssl, :only => [:some_method]
  def require_ssl
    redirect_to params.merge!(:protocol => "https://") unless request.ssl? or !use_ssl?
  end

  # Usage: before_filter :no_ssl, :only => [:some_method]
  def no_ssl
    redirect_to params.merge!(:protocol => "http://") if request.ssl?
  end

  # If you need to test SSL, you may want to configure it up on a development box
  # App::Config is a separate post, let me know if you want me to write it up
  def use_ssl?
    !local_request? || App::Config.ssl_for_local
  end

So I think the comments are more or less self explanatory, but in case they’re not… By default, all controllers will happily accept both SSL and non-SSL requests. You can use these filters to flip a request to the right protocol; before_filter :require_ssl for private information, and before_filter :no_ssl for the more common, low-energy requests. I also add a before_filter :no_ssl in my ApplicationController, since I’d rather be conservative about resource consumption. If you’re more worried about information leak, you can define the opposite default. If you do define a default, don’t forget to add the corresponding skip_filter when you want to change the protocol. The params.merge! is tricky and very important. When I first deployed my service with SSL… in production…. with inadequate testing… I did the simple redirect_to :protocol => "https://" and I had some key requests redirect to localhost! That was not a good thing. You want to keep all the params of the original request, just change the protocol. The use_ssl method is clever, and I wish I had thought of it myself (see below). If the request originates from the local box, there’s no point in using SSL; it turns out, that covers your development box quite nicely. However, that also means that when you’re setting up your service, you can have problems that are only discoverable in production (or, we hope, integration); so when I am working on actually putting the SSL in place, I (sigh) configure my local box for SSL and test the hell out of it. Because I don’t want to redirect my customers to localhost ever again.

Step II: Inbound information

Most of the sites I’ve seen discussing this topic present a variant of the filters above and then claim victory. However, you probably don’t want to be sending your passwords across in plaintext, which means you need to make sure that they use https when appropriate. Your login page is hit very frequently, and you probably don’t want to require that it use https. So we want to be able to render a page via http, and then submit the form via https. I struggled with this for a while; many of the built-in Rails primitives flat out suck when presented with a :protocol option. So the best I could come up with was to write a reasonably flexible façade over them. If I were more motivated, or more experienced, I would probably have dug into the Rails source and fixed this, but I’m neither. First, let me show you the usage. Consider a typical form (in this case, a :user has_many :contact_data):

  - form_for([@user, @contact_datum]) do |f|

We want to modify this as little as possible. Ideally we’d just add the :protocol to the form_for, but sadly that just don’t work. The best solution I was able to come up with, after a fair amount of web research, coding, and swearing, was the following:

  - form_for([@user, @contact_datum], {:url => ssl_url_for([@user, @contact_datum])}) do |f|

I put this in my ApplicationHelper:

  # This is a simplified RESTful route generator.  Given an object, it generates a URL (via url_for)
  # and defines the full URL including protocol if the requested protocol doesn't match the current protocol.
  # By default it will use the ssl protocol defined by the ApplicationController.ssl_protocol method
  # 
  # +objects+ an object or array of objects similar to those passed to a form: [@container, @target].
  #                We allow the target to be an integer, in which case we assume it's an object id and require
  #                that the action and controller be specified explicitly (see below)
  # +action_name+ (optional) the action to invoke.  If not supplied, :create or :update is inferred from
  #                          whether the target is new or has been saved.
  # +options:+
  #    :controller => <controller> the name of the controller, eg :users
  #    :protocol   => "http://" to force a non-SSL form submission from an SSL rendered page
  # 
  def ssl_url_for(objects, action_name = nil, options = {})
    objects = Array(objects)
    target = objects.pop
    # We're almost always going to want to use SSL, but not on my local box and 
    # not if the user demands something else
    protocol = options[:protocol] || (use_ssl? ? "https://" : "http://")
    # If no controller is specified, infer it from the class of the target
    controller_name = options[:controller] || target.class
    controller_name = pluralize(controller_name.to_s, 2).underscore

    # If the target isn't numeric, infer the action_name (if not specified) from the target's state
    if !target.kind_of?(Numeric)
       action_name ||= target.new_record? ? :create : :update
    end

    url_hash = {
      :controller => controller_name,
      :action => action_name,
      :protocol => protocol,
    }
    # grab an id, unless the target is a new object, in which case there is no id to be grabbed
    if target.kind_of?(Numeric)
      url_hash[:id] = target
    else
      url_hash[:id] = target.id unless target.new_record?
    end

    # If the protocol we want doesn't match the protocol for the page we're, we need to render the full URL
    url_hash[:only_path] = false unless (request.ssl? ? "https://" == protocol : "http://" == protocol)

    # For each of the remaining objects in the original array (if any), add a reference to its id by class
    objects.each {|object| url_hash["#{object.class}_id".downcase.intern] = object.id}

    # Whew.  That was easy.  Render me a URL!
    url_for(url_hash)
  end

So that’s not nearly as self-explanatory, and I’m afraid I’m not going to do a lot more to explain it than the comments in the code itself. Most of it is syntactic sugar so I can use the same method with an object or an id as appropriate.

---

Thanks to:

• Setting up your rails application to use SSL
• Using local_request? to decide whether to use SSL in development
• Midnight Oil