The YZA

I use a Mac at my day job. It had been years since I’d used a Mac every day — my father bought my Apple sales pitch when I was in the fourth grade and we bought an Apple IIGS (“Graphics & Sound”) for something like US$4000 (and that’s in 1989 dollars, which is US$6860.57 in 2008 dollars according to the inflation calculator). The machine had no hard drive, and at the software store there was exactly one wall of Apple software, as compared with over a dozen walls of PC software (lots of walls at this software store, like a maze).

After a couple years of school reports and Where in the World is Carmen Sandiego?, I realized that PCs were where it was it — lots of software, cheap, lots of hardware options, and most importantly for 13 year old me (and probably for 26 year old me, too): tons and tons of computer games were made for PCs. So we ditched the Apple and bought a Gateway and thereafter I became a PC guy. I admire my old friend Martin Stabe who tricked out his Apple IIGS and used it through high school (till 1997! Maybe even beyond!). Maybe if my parents hadn’t caved in to every consumer whim I had as a child, I’d be better with my money.

Anyway, here I am, using a Mac every day, and realizing that Windows XP sucks to use after using OS X Leopard, and that for software (including games) that needs to run on a Windows machine, I can use Virtualization software like VMWare Fusion or Parallels or the free VirtualBox. So I wanted a Mac machine, but I wasn’t about to spend buckets of dough on an overpriced Apple computer. I decided that I was going to attempt to install OS X on PC hardware, something people have been doing for a few years ever since Apple started shipping Macs with Intel chips (the same chips that PCs use).

So I went to the Insanely Mac forums and read for a while and at first found it really confusing, inundated by too much information, or missing information, or misinformation. The site is entirely dedicated to people hacking OS X to get it to run perfectly on regular, Newegg bought PC hardware. Eventually, I decided what hardware to buy — the motherboard and video card are probably the most difficult choices to make, as your compatibility with OS X will depend heavily on those two pieces of hardware. I bought the stuff, put it all together, and less than two weeks later, after dozens of installs and re-installs, I have the machine almost fully operational. I’ll share details soon.

Since I haven’t written to this blog in ages, and I have been spending a lot of time working on Rails applications, and I need to document some of the processes of my work somewhere, I figured I’d put them here for the edification of anyone who finds him or herself needed the same questions answered that I did. I definitely googled a shit-ton while looking for answers, and as I did that I thought to myself “My lord, people really do spend a lot of time helping others for no material gain. How have I contributed?” I hadn’t, until now. For all you loyal readers of my writing who expect the regular diatribes concerning the regular things people rant about (politics, art, etc), you can safely ignore these posts without missing too much of me. So here goes:

One of the sites I’ve been working on was found to have a security hole (I won’t say which site, for obvious reasons). It turns out that with Rails, if you sniff or otherwise procure the session ID that’s set in a visitor’s cookie (which is normally sent as plain text), you can then make requests to that Rails app as if you were that visitor as long as the session ID is still valid (meaning you could pretend to be that visitor without actually knowing his/her username or password — all you need is that session ID).

One of the solutions to this (besides making the entire site secure and served via https) is to set a secure authentication token (in the form of a cookie) when a visitor logs in. So now we have two cookies: the session cookie that contains the plain-text session ID, and the authentication token cookie, which, for now, contains an encoded string that I’ll explain below. When a visitor logs in to the secure login page, the authentication token is set and sent over https. Then, for the rest of that visitor’s browsing session (meaning until he/she closes his/her browser), all secure requests from that visitor ask if the authentication token is present and valid. If it is, then the request works fine and the visitor gets back whatever page he/she was requesting. If not, the request is redirected to the login page. Since the authentication token is always sent via https and never as plain-text, the only way an attacker could steal it is to harvest the cookie straight from the legit visitor’s machine (via some sort of spyware or virus script).

So I had to implement all this, but because my development environment used Mongrel, I had no way to serve https pages locally (Mongrel, which is the defacto Rails server, has no built in https support). So I had to change the way I was doing things on my local box before I could code and test my secure authentication cookie. I did some research, and found that the best and easiest solution was to install Passenger (aka mod_rails) as an Apache module, and then use Apache to serve all my pages locally (Apache has SSL support). While I’d deployed onto boxes with Passenger, I’d never considered installing it locally (I guess because it’s not available on Windows and I’ve only just started using a Mac again fairly recently). It turns out it’s a cinch to install, and on OS X there is also a Preferences pane that you can install to make setting up local sites that much easier.

So once you have Passenger set up properly and the (Apache) virutal hosts set up on your development machine, you should create a self-signed security certificate, which you can find instructions to do here. This will be used for your secure pages, and should only be used in development or staging environments because your browser will inevitably throw up a warning when you hit a secure page using this certificate. In production, you have to get some authority to sign your certificate (like GoDaddy.com or some other secure certificate service).

Once I had all that set up, then it was time to modify my Rails app to allow it to serve secure pages, and to set up the login and admin pages to always serve via https. This is easily done once you install the ssl_requirements plugin into your Rails app. It’s a small plugin that lets you easily require or allow certain pages of your Rails app to be served over https — just add something like

class AccountController < ApplicationController
ssl_required :signup, :payment
ssl_allowed :index

to your controller. This will force the signup and payment actions of that controller to use https (any requests to those pages via http will be redirected), and this will allow the index action to be served via https, but also regular http. All other actions of this controller will be forced to use http, and will be redirected to use that protocol if the inital request is https.

That’s pretty much it. Now I can test https locally, and I can easily run multiple rails apps simultaneously. If you read this and want to know any specifics, feel free to leave a comment.