Securing a Rails app on Passenger with SSL

Posted by Brian in Howto, Rails, tips, web (July 24th, 2012)

Configuring a site for SSL is simple once you understand the process. Unfortunately I don’t set these up all that often so I forget. In my book Web Development Recipes I cover how to set up the certificates on the Apache server, but I don’t explicitly show how to make it work with a Rails application. So here’s how I usually set things up.

Assume we have a Linux-based server running Ubuntu (either 10.04 or 12.04), we keep our sites in /var/www and we will define our virtual host in the file /etc/apache2/sites-available/mysite

We want to make sure all HTTP requests go to HTTPS. To do that, we need to set up security for the site *and* add a redirect, either at the application level or at the server level. Many folks will recommend using Rack:SSL, but I’m just going to let Apache take care of it for me.

To make all this work we’ll need to enable two Apache modules; ssl and rewrite. The rewrite mod may already be enabled so you should scan your /etc/apache2.conf or your other configs for it.

To enable the mods, we use the a2enmod command:

$ sudo a2enmod ssl
$ sudo a2enmod rewrite

Next we need to modify the site definition in /etc/apache2/sites-available/mysite so it uses SSL and our certificates. First we’ll change the host for HTTP on port 80 so it redirects traffic to the secure site, like this:


  ServerName myapp.example.com
  RewriteEngine On
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=permanent]

I’m using named virtual hosts here, so this rewrite only applies to myapp.example.com and none of the other sites I may have set up.

In the same file, we add the definition for the secure site on port 443, the default SSH port. This contains all the info that Passgener needs to spawn the site.


  ServerName myapp.example.com
  DocumentRoot /var/www/myapp/current/public
  
    AllowOverride all
    Options -MultiViews
  

  SSLEngine on 
  SSLOptions +StrictRequire 
  SSLCertificateFile /etc/apache2/certs/myapp.example.com.crt 
  SSLCertificateKeyFile /etc/apache2/certs/myapp.example.com.key 

To make this work, we have to generate the certificate and the key.

We do that by creating the /etc/apache2/certs folder and changing into it:

$ sudo mkdir /etc/apache2/certs
$ cd /etc/apache2/certs

Then we generate our Certificate request which also generates a key.

$ sudo openssl req -new -newkey rsa:2048 -nodes -keyout myapp.example.com.key -out myapp.example.com.csr 

Then we take the csr file and get it signed by the cert admin. Or if we need things secured temporarily, we could
sign it ourselves, knowing that our users will get a nasty warning about unknown certs.

$ openssl x509 -req  -in myapp.example.com.csr \
 -signkey myapp.example.com.key -out myapp.example.com.crt

You really don’t want to go to production with a self-signed certificate though.

Once these files are in the certs directory, we can restart the web server and everything should work as expected.

Moving from Prototype to JQuery

Posted by Brian in tips, web (November 15th, 2009)

On a recent project, I converted a ton of Javascript from Prototype to jQuery in order to take advantage of many of the nice UI elements available. As I did the conversion, I took down some notes that I wanted to share with you about the differences between the two libraries. In some cases, the differences are insignificant, and in a couple of others, the differences merely come down to a difference of opinion among the developers and supporters of the libraries.

Here are the notes:

Getting Ready

Before you can work with elements on the page, those elements must be loaded.

Prototype uses

document.observe("dom:loaded", function() {
  // your functions
})

jQuery uses this:

$(document).ready(function(){
  // your functions
})

Finding things

In Prototype, you use $() or $$() to locate elements. With $() you use the ID, whereas with $$() you use a CSS selector.

  var header = $("header");  // a single element, 

With JQuery, you do almost all of your element location using $(), which works very much like $$() in Prototype.

  var header = $("#header");  // a single element, 

Binding events

Prototype’s Element class has an Observe method. It’s very easy to use and easy on the eyes.

  $("header").observe("click", function(event){
    alert("Hi there");
  });

In jQuery, it’s nearly identical, except that click is a method on the JQuery object.

  $("#header").click(function(event){
    alert("Hi there");
  });

At first, the differences look marginal, but let’s look at a more complicated example:

In Prototype, to find all links on the page with the class “Popup” and make them open in a new window, you have to do this:

function new_window_links(){
  links = $$("a.popup");
  links.each(function(link){
    link.observe("click", function(event){
      window.open(link.href);
      event.stop();
    });
  });
}

The Prototype version makes us find all of the elements, loop over them, and then apply the observer to each one.

jQuery can hide the iteration from you, which results in somewhat cleaner code.

function new_window_links(){
  links = $("a.popup").click(function(event){
      window.open($(this).attr('href'));
      event.preventDefault();
  });
}

Adding Classes

Prototype:

   $(".foo").addClassName("ninja");
  $(".foo").addClass("ninja");

Traversing the DOM

Prototype:

  parent_of_foo = $("foo").up();

jQuery

  parent_of_foo = $("#foo").parent();

Working with HTML attributes

This one was the most difficult to get used to. In Prototype, many of the HTML attributes are available as methods on the Element class.

  window.open(link.href);

In jQuery, you use the attr method to get and set the attributes.

  window.open(link.attr("http");

This illustrates only a few of the differences between the libraries, but as you can see, the differences don’t realy amount to anything substantial. Both of these libraries greatly simplify cross-browser JavaScript development, so no matter which you choose, you’ll be in good shape.

“Meet Rails” presentation materials from Chippewa Valley Code Camp

Posted by Brian in Howto, Rails, tips, web (November 24th, 2008)

I gave a talk at the Chippewa Valley Code Camp earlier this month where I built a Rails pastebin application using test-first development principles. Since there were no slides for this, I’ve prepared a small PDF that will walk you through the installation instructions and the coding of the application I built.

Download Meet Rails to get started.

You can grab the source code for the finished project at Github.

Watch this site, as this project may get turned into a full-scale book.

“Web Design for Developers” now available in Beta

Posted by Brian in News, Products, Projects, Usability, web (November 19th, 2008)

Web Design for Developers

My book Web Design for Developers is now available in Beta form.

You’ll learn how to design a web site from start to finish, and you’ll use many of the techniques and thought processes you’ve come to rely on as an application developer. You’ll learn some color theory, some typography basics, some XHTML and CSS, and how to incorporate Photoshop and Illustrator into a work flow that works for you, not against you.

You can buy an early copy and then contribute to the feedback cycle to help make this an even better book when it eventually ships. You can purchase the PDF and start reading now, or preorder the printed book which will ship after the beta process finishes up.

Slides and Materials from “Web Design for Programmers”

Posted by Brian in News, web (June 4th, 2008)

The slides from my RailsConf 2008 tutorial session are now available. Grab the PDF version.

Unfortunately, the handouts I sent were printed in black and white so some of the color examples don’t work as well. Grab color ones instead.

If there are additional materials from the presentation that you want to see, let me know and I’ll see what I can do.

Why I’m using a Mac

Posted by Brian in News, Rails, Usability, web (May 9th, 2007)

I’m a Windows user. Anyone who reads this blog can pretty much figure that much out. I started this company in 1995, fixing computers and trying to put the “personal” in computer service.
Over the years, I’ve removed countless viruses, uninstalled lots of spyware, formatted hard drives, recovered files, and occasionally had to send a computer back to a customer as “unfixable” because
of some unknown hardware or software glitch. Windows is popular and well-known, and people who know it well can have some pretty good job security.

Shortly after I started this company, I shifted focus towards the Internet, developing web sites. I bucked the trend of my Mac-using
counterparts back then and did all of my design work on Windows. I even did video editing there. I embraced ASP, and when that got old, I started using PHP, but deployed on Windows.

When Ruby on Rails came along and I got involved in that community, I was determined more than ever to bring Rails to the Windows platform. I’m speaking about Rails on Windows at RailsConf 2007 this year, and I’ve just finished a book on
Rails for Windows users which will be published by O’Reilly.

But I started using a Mac for development this Spring and couldn’t be happier. Here’s why.

  1. Ruby runs faster.

    Ruby runs at least ten times faster on a Mac, which means my unit tests, Rake tasks, and anything else I do with Ruby take no time to run. On Windows, I pay at least a 15 second penalty just to start a task or a test. That basically means I either sit and wait for things to happen, or I just start neglecting my tests to save time. Not a good place to be if you’re trying to write good code.

  2. It’s Linux that runs Photoshop

    Many web-based languages like PHP, Python, and Ruby run extremely well on Linux. However, you can’t use industry-standard tools like Photoshop on Linux without a few glitches and a lot of work. I’ve done Photoshop on Wine and I am not impressed. On my Mac, I can use Flash, Photoshop, Illustrator, Dreamweaver, and anything else, because there are native supported ports of those programs for my system.

  3. I can run Windows apps too!

    I need Office, and I need to run IIS so I can support ASP, .Net, and other Microsoft-based technologies. My Macbook Pro has Windows XP installed as a second boot option, but I also run Windows XP on Parallels, a virtual machine that lets me use my Windows apps side-by-side with my Mac programs. Parallels can run pretty much any other operating system, so I also have Windows Server 2003 installed for testing.

    When I go to conferences, I only have to bring one computer.

  4. I can surf in peace

    No IE means no spyware. I typically use Firefox on Windows anyway, but the complete absense of IE on this machine makes me feel much safer.

  5. More time working, less time tweaking

    I don’t have to stop working in order to make something do what I want. The Mac’s OS gets out of your way and lets you work. It’s a little difficult to transistion from a PC to a Mac at first, but some of the built-in features are great. The Dashboard gives me quick access to GMail, my WordPress blog, the weather, my Backpack account, and even a color-picker.

    When I got my Macbook, I was using it and actually being productive with it in only a few hours. I haven’t used a Mac since I was a kid.

  6. Textmate

    Windows users have e, but I have TextMate, and I don’t need anything else. TextMate is more than just a text-editor; it’s an IDE. I can integrate with Subversion, I can run Rails generator commands, I can run unit tests, and I can have Prototype and Script.aculo.us methods auto-complete while I type. I can validate HTML, preview in a browser, and then upload it back to my repository.

  7. I can use more advanced tools

    I do most of my deployment on shared hosts with Mongrel and mongrel_cluster. I can run these on my Mac without incident. I also use the excellent load-testing program httper, which does not run on Windows. There are countless other tools out there too.

    I also get to use QuickSilver, which means I can chain commands and navigate through my files and programs much faster.

  8. Apple has awesome support

    I used my new Macbook Pro for gaming one night just to try it out. My games ran flawlessly when I boot into Windows XP via Bootcamp. While I was playing, one of my keys came dislodged. I called up Apple, and within 10 minutes I had them sending me a new keyboard. That’s cool. Try getting that from another company. I’ve worked with tech support offices for the last 13 years, and I rarely get service like that. Good luck getting that from some of the larger PC manufacturers unless you have an enterprise support contract.

  9. I can zoom.

    OS X has a built-in zoom feature that I use to not only enlarge the screen when I need it, but also to inspect images for artifacts and imperfections.

So there you have it, a long-time Windows user who is using a Mac for software development. If you’re going to preach to others about “using the right tool for the job” then you owe it to yourself to see what a Mac can do for you.

If you have switched, I’d love to hear your story. If you’re thinking about getting one, let’s hear what’s holding you back from taking the plunge.

IE Web Developer Toolbar?

Posted by Brian in Accessibility, Browsers, web (April 24th, 2007)

There’s a toolbar for Internet Explorer that has many of the same features as Firebug for Firefox.
Visit http://www.microsoft.com/downloads/details.aspx?familyid=e59c3964-672d-4511-bb3e-2d5e1db91038&displaylang=en to get a copy of the current beta.

To launch it, start IE7 and go to Tools -> Toolbars -> Explorer Bar -> IE DOM explorer.

You can inspect the DOM, the HTML elements, the CSS, and much more. It’s great to have this available!

Is XHTML bad for you?

Posted by Brian in Accessibility, Browsers, News, web (April 17th, 2007)

What do you do when you are confronted with the possibility that everything you know is wrong, or that you’re doing things not because they’re good, but because everyone else is doing it?

It seems that there are issues with using XHTML instead of HTML, and I think this is something that any web developer needs to investigate further.

From the article:

If you’re a web developer, you’ve probably heard about XHTML, the markup language developed in 1999 to implement HTML as an XML format. Most people who use and promote XHTML do so because they think it’s the newest and hottest thing, and they may have heard of some (usually false) benefits here and there. But there is a lot more to it than you may realize, and if you’re using it on your website, even if it validates, you are probably using it incorrectly.

This website uses XHTML 1.0 Transitional, apparently incorrectly.

All links open in a new window.

Other links: