James Adam

Back in 2011, when I started getting back into this whole web thing, I rented a VPS from the folks over at ServInt to run a website called RhythmScore (my first attempt at a web-based business — it failed, hard… maybe I’ll write about it sometime after the sting wears off).  Now, ServInt offers managed VPSes, which means they basically handle a lot of the routine system administration tasks for you.  At the time I thought this was a good thing since while I fancy myself a good programmer, as a sysadmin I know just enough to be dangerous.

As time went on, I upgraded the VPS with more ram, disk space, etc., and also began hosting a few more websites and rails apps on it, including this blog.  Now, a managed VPS comes at a higher cost than a comparable unmanaged solution, and since I’ve become more comfortable tinkering with web servers, databases, etc., I decided to explore other options to host my blog (and possibly a few other simple sites).  In fact, my preference now would be to run multiple, cheap VPSes that can be configured especially for the applications that will be running on them.  With my ServInt VPS running $60, I was trying to run everything on it.  RhythmScore was a PHP website running with MySQL.  My old blog was a Rails app running the Refinery CMS.  I also was hosting a static website for a friend, as well as another rails app.  All of this of course using Apache, mod_php, and Passenger.

This time around I wanted to simplify things.  A single, lean, VPS for running PHP and static websites, and then an independent VPS for each rails app I want to deploy (because running multiple versions of rails on the same production server can be a pain — and yes, I do use rvm, but only on my development box).  In fact, for my upcoming rails app (second attempt at a web-based business), I plan to run an additional VPS running just the database server.

Anyway, I’m starting to ramble.  I located a company called 6sync that sells VPSes at a wide variety of price points.  Another upshot is the ability to choose which linux distro you want to run.  I’ve always been a Debian man myself, but ServInt (along with most other managed hosting providers) pretty much forces you into CentOS, which I hate, along with Fedora, RHEL, and any other rpm-based distro.

So, I bought a $15 ‘nano’ instance from 6sync and spun up a 32-bit (hey, the nano instance has only 256MB of RAM) Debian 6 server.  I ssh-ed (not sure if I can use ssh as a verb, but I’m going to anyway) into my server and discovered a nice minimal Debian install ready to be configured.

Being in the mood to experiment, I wanted to try using Nginx (pronounced engine-x), rather than Apache, because I heard Apache was old and busted and I wanted to be cool.  Unfortunately, I couldn’t find very many guides on setting up a LEMP (Where the E stands for “engine-x”, as opposed to the more well known LAMP)  stack on Debian, so I had to piece together information gleaned from various sources on the intertubes to come up with something that worked.

First, I added the dotdeb sources  to my /etc/apt/sources.list file:

deb http://packages.dotdeb.org stable all

That done, I then made sure my package database was up to date:

apt-get update

Now, the first step is to install MySQL:

apt-get install mysql-server mysql-client php5-mysql

There, that was easy. Next up is Nginx.
Now Nginx is pretty easy to install, though some people may want to compile from source because they are nerds, but I am not a nerd. I just spend all of my spare time programming and writing about it on my blog, because I’m not a nerd. Anyway:

apt-get install nginx

Of course, I’m also going to need PHP if I want to run WordPress:

apt-get install php5 php5-fpm

Now, there is one configuration change needed to php.ini to start with. In the file /etc/php5/fpm/php.ini, I found the line:

cgi.fix_pathinfo=1

and changed it to:

cgi.fix_pathinfo=0

Ok, that’s done. Now for the fun part of actually configuring the web server. Since I plan to run multiple websites from this VPS I’ll need to set up a few virtual hosts. I was actually surprised at how much easier this is to do on Nginx than Apache. For my first site, jamesadam.me, I set up a new user, jcadam, with a home directory at /home/jcadam as follows:

adduser -g www-data jcadam

Then, in the /etc/nginx/sites-available directory, I created a new file called http://www.jamesadam.me, and configured it thusly:

 server{
        listen 80;
        server_name jamesadam.me www.jamesadam.me;

        access_log /var/log/nginx/website.access_log;
        error_log /var/log/nginx/website.error_log;

        root /home/jcadam/public_html;
        index index.php index.htm index.html;

        location ~ .php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME /home/jcadam/public_html$fastcgi_script_name;
                include fastcgi_params;
        }

        location / {
                index index.php index.html index.htm;
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }
}

I made a link to this file in the /etc/nginx/sites-enabled directory also:

ln -s /etc/nginx/sites-available/www.jamesadam.me /etc/nginx/sites-enabled

I want my web files to be served from /home/jcadam/public_html. The ‘location ~ .php$’ section is needed to enable PHP support. That last line containing the ‘try_files’ command I added later, after I discovered that the pretty permalinks in WordPress wouldn’t work without it.
My first test was to create a test page at /home/jcadam/public_html/index.php that contained nothing but the phpinfo() command. Since that worked, I figured it was time to go on and install wordpress.
First, I downloaded wordpress:

wget http://wordpress.org/latest.tar.gz

and unzipped it into my public_html directory.
Next, I suppose WordPress would like a database to work with. So, I logged into mysql as the root database user(which I set up when I installed MySQL) and issued the following commands:

CREATE DATABASE wordpress;
CREATE USER the_user@localhost; #No, not my real user name :)
SET PASSWORD FOR wordpressuser@localhost= PASSWORD("12345"); #No, not really my password.  Luggage combination, yes.
GRANT ALL PRIVILEGES ON wordpress.* TO the_user@localhost IDENTIFIED BY '12345'
FLUSH PRIVILEGES;
exit

After that, I connected to my server using a web browser and went though the WordPress web-based configuration with no trouble… though I did need to set up my wp-config.php file manually, but that was not difficult 🙂

I’m currently neck-deep in a new project using Rails 3.2 and Active Scaffold.  If you’re unfamiliar with Active Scaffold, it’s a great plugin that takes care of most of your application’s CRUD functionality.  If you’re working on a data-heavy application, you should check it out.

Anyway, as great as Active Scaffold is, it certainly isn’t perfect.  The controller_generator script generates functional tests for you.  Nice, except that several of them don’t work out of the box — primarily the tests for creating and updating records.

For example, here is the create record test that was automagically generated for one of my controllers:

  test "should create student" do
    assert_difference('Student.count') do
      post :create, student: {
          age: @student.age,
          first_name: @student.first_name,
          gender: @student.gender,
          grade_level: @student.grade_level,
          last_name: @student.last_name }
    end
    assert_redirected_to student_path(assigns(:student))
  end

Nothing obviously amiss, right? Wrong.  Running the functional tests gets you the following error:

Error: test_should_create_student(StudentsControllerTest)
  NoMethodError: undefined method `each' for nil:NilClass

A little bit of troubleshooting reveals that the error is coming from deep within the bowels of Active Scaffold.  There was a time when I would have just jumped in and started hacking third party code, assuming that I was right and the API/library I was using was wrong.  These days I’m a little older and hopefully a little wiser, so I figured I should probably at least try to make changes to my code first.

A little bit of poking around on Active Scaffold’s github site reveals that I’m not the only person experiencing this issue.

Anyway, the solution is to change the params key from your model name to record, so the line:

     post :create, student: {

becomes:

     post :create, record: {

Rerunning the tests, I get a new error:

    ActionController::RoutingError: No route matches {:action=>"show", :controller=>"students"}

After I gaped dumbly (blinking occasionally) at both the test log and my code, I noticed that Active Scaffold had generated the last line of my test incorrectly:

      assert_redirected_to student_path(assigns(:student))

It’s kind of subtle, but that should be students_path, not the singular student_path.  Making that change now allows the test to pass.

Making similar changes to the “should update student” test allows that one to pass as well:

  test "should update student" do
    put :update, id: @student, record: {
        age: @student.age,
        first_name: @student.first_name,
        gender: @student.gender,
        grade_level: @student.grade_level,
        last_name: @student.last_name }
    assert_redirected_to students_path(assigns(:student))
  end

That should do it, right?  Um, not exactly.  The real bashing-head-into-keyboard-repeatedly-error has yet to be dealt with.  You see, Active Scaffold generated a pretty standard looking test for retrieving the index page:

  test "should get index" do
    get :index
    assert_response :success
    assert_not_nil assigns(:students)
  end

But running the test yields yet another problem:

=========================================================================
Failure:  expected to not be nil.
test_should_get_index(StudentsControllerTest)
test/functional/students_controller_test.rb:13:in `block in '
     10:   test "should get index" do
     11:     get :index, :current_user => @user
     12:     assert_response :success
  => 13:     assert_not_nil assigns(:students)
     14:   end
     15: 
     16:   test "should get new" do
=========================================================================

Say what?! C’mon… that should just work.  After all, getting the index page in a web browser works just fine.

Consider, however, what Active Scaffold is actually doing when you request the index page from a particular controller.  It doesn’t just display a list of records, it calls a :list action, which displays a list of records.  So perhaps we should test the ‘list’ functionality separately, while making sure that get :index at least renders the list template.

So, first we add a new test for :list

  test "should get list" do
    get :list
    assert_response :success
    assert_template 'list'
    assert_not_nil assigns(:page)
    assert_not_nil assigns(:records)
  end

Then, we modify the get :index test as follows:

  test "should get index" do
    get :index
    assert_response :success
    assert_template 'list'
  end

Whew! Everything passes. Time to go get some more coffee…

While building an online store for one of my past projects using Rails and the Refinery CMS, I was presented with an interesting problem. I had a requirement to allow customers to purchase and download individual music tracks directly from an online store that also sells physical goods. On its surface, this sort of thing does not seem much different from selling tangible goods via the web: User selects items, places them in his/her cart, and checks out. After payment processing, the only thing different in the case of digital downloads would be in actually fulfilling the order.

The problem is not in getting the purchased tracks to the customer. It’s easy enough to email a link to the purchased files. However, a permanent link to your digital downloads would allow anyone to grab the files you’re trying to sell, for free. So, clearly a better solution is needed that will deny everyone but paying customers access to downloadable products.

A thought briefly occurred to me to just email the purchased tracks to the customer after a purchase was made. But that’s head-smackingly stupid for a number of reasons, not the least of which is the fact that many email providers place a size limit on attachments that would prevent this solution from working. Plus, what if a customer loses his emailed copy and wants to get the files he payed for a second time? Sure, you could tell him/her to just buy them again, but that’s not the kind of customer service that will engender loyalty and/or referrals.

A better solution would be to provide each customer with an access code that will allow him/her to access a download page containing all of the files purchased as part of a particular order. The Refinery CMS does a decent job of preventing unauthorized access to resources (our downloadable files, for example) that aren’t meant to be public, so a good amount of the work has already been done.  However, one requirement of this project introduced another problem: PayPal was being used for order processing. The issue with using a third-party payment processor like PayPal is that you can’t know for sure if a customer’s payment was processed successfully after being forwarded from the main store.

Fortunately, PayPal provides a service it calls Instant Payment Notification (IPN). Basically, it works like this:
1.) A customer is forwarded to PayPal from your website to complete his purchase.
2.) Paypal processes the payment, and then sends a notification to a listener you’ve set up on your site
3.) The listener verifies that the payment notification is valid by sending it, unaltered, to PayPal
4.) If the notification is legit, PayPal sends back a final, one-word response, either INVALID or VERIFIED.

The IPN also contains all the information forwarded to PayPal when transferring the user from your site, along with some details provided to PayPal, such as the customer’s email address.  So, if you set up your store correctly you should receive everything you need to fulfill the order.

So, armed with this information, the final process for digital download sales is as follows:

1.) Customer purchases files via PayPal
2.) PayPal sends an IPN to the website’s listener
3.) The listener verifies the IPN.
4.) If verified, the listener generates an access code and sends an email to the customer containing a link to a download page.

Setting up a listener is easy if you use ActiveMerchant, as it includes built in support for PayPal. Here’s an example using a simple five digit number for an access code (not the most secure thing in the world, you might want to use a longer string that can consist of the full gamut of alphanumeric characters). We hash the access code using MD5 and store the hash in the database.  Here’s an example controller for a PaymentNotification model:

class PaymentNotificationsController  [:create]

  def create
    notify = Paypal::Notification.new(request.raw_post)
    Rails.logger.info "In create"
    #Verify IPN with PayPal
    if notify.acknowledge
      Rails.logger.info "Acknowledge"
        if notify.complete?
          Rails.logger.info "payment complete"
          notification = PaymentNotification.create!(:params => params, 
            :cart_id => params[:invoice], :status => params[:payment_status], 
            :transaction_id => params[:txn_id])
          Cart.find(params[:invoice]).update_attribute(:purchased_at, 
            Time.now)
          #Generate access code
          random_number_generator = Random.new
          random = random_number_generator.rand(10000...99999)
          hashed_random = Digest::MD5.hexdigest(random.to_s)
          #store access code in database
          notification.update_attribute(:access_code, hashed_random)
          #Send Email notification
          OrderNotifier.received(notification, random).deliver
        else
          Rails.logger.error("Failed to verify Paypal's notification")
        end
    end
    render :nothing => true
  end
end

And if you’re curious about the PaymentNotification model itself, it’s pretty simple:

class PaymentNotification  :create
  validates_presence_of :cart_id, :on => :create
  validates_uniqueness_of :transaction_id
  validates_uniqueness_of :cart_id

  serialize :params
end

The data we need is pulled from the IPN itself (contained in :params). The cart_id is the id number of a cart in the site’s database that contains the customer’s order. This was forwarded to PayPal when the customer checked out and is returned as params[:invoice]. The :transaction_id (returned as params[:txn_id]) is a unique identifier assigned to the order by PayPal.

OrderNotifier is just a child of ActionMailer, and it’s used to send the transaction_id and access code to the customer:

class OrderNotifier  

  def received(notification, random)
    @notification = notification
    @code = random
    @greeting = "Hello"
    @cart = Cart.find(@notification.cart_id)
    mail :to => @notification.params[:payer_email]
    #mail :to => "nobody@nowhere.com"
  end
end

The email sent to the customer would contain a section that goes something like this:

To get your files, please visit the following link and enter your transaction ID and access code:
  http://www.example.com/carts/
  Transaction ID : 
  Access Code    :

When the customer visits the provided link, he’s presented with a form requesting the transaction ID and access code:

Entering the correct information would then present the user with a page containing links to the downloads he ordered. There are numerous variations on this basic system one could do. For example, with a few small modifications one could easily limit the number of times a user could download his/her files to, say, five. There are also third party solutions available to manage digital download sales, though I haven’t tried any yet.