ITERATION C1: CREATING A CAR T 78

Figure 8.1: Model, Schema, and Classes for belongs_to

ITERATION C1: CREATING A CAR T 79

ITERATION C1: CREATING A CAR T 80

4If you don’t see a list of products, you’ll need to go back to the administration section of the application and add some.

ITERATION C1: CREATING A CAR T 81

page. (Although not in Rails 0.13.1 or later, where the steps on this page are no longer necessary.)

ITERATION C1: CREATING A CAR T 82

Figure 8.2: Our Cart Now Has an Item in It

ITERATION C1: CREATING A CAR T 83

Session Information, Serialization, and Classes

The session construct stores the objects that you want to keep around between browser requests. To make this work, Rails has to take these objects and store them at the end of one request, loading them back in when a subsequent request comes in from the same browser. To store objects outside the running application, Rails uses Ruby’s serialization mechanism, which converts objects to data that can be loaded back in.

However, that loading works only if Ruby knows about the classes of the objects in the serialized file. When we store a cart in a session, we’re storing an object of class Cart. But when it comes time to load that data back in, there’s no guarantee that Rails will have loaded up the Cart model at that point (because Rails loads things only when it thinks it needs them). Using the model declaration forces Rails to load the user model class early, so Ruby knows what to do with it when it loads the serialized session.

Hit Refresh in our browser, and (assuming we picked a product from the catalog) we’ll see it displayed.

1 Pragmatic Project Automation 29.95 29.95

Hit the Back button (we’ll work on navigation shortly), and add another.

Looking good. Go back and add a second copy of the original product.

1Pragmatic Project Automation 29.95 29.95

ITERATION C1: CREATING A CAR T 84

else

item = LineItem.for_product(product) @items << item

end

@total_price += product.price end

The problem we now face is that we already have a session with duplicate products in the cart, and this session is associated with a cookie stored in our browser. It won’t go away unless we delete that cookie.5 Fortunately, there’s an alternative to punching buttons in a browser window when we want to try out our code. The Rails way is to write tests. But that’s such a big topic, we’re putting it in its own chapter, Chapter 12, Task T: Testing, on page 132.

Tidying Up the Cart

Before we declare this iteration complete and we show our customer our application so far, let’s tidy up the cart display page. Rather than simply dumping out the products, let’s add some formatting. At the same time, we can add the much-needed Continue shopping link so we don’t have to keep hitting the Back button. While we’re adding links, let’s anticipate a little and add links to empty the cart and to check out.

Our new display_cart.rhtml file looks like this.

<table cellpadding="10" cellspacing="0">

<tr class="carttitle">

<td rowspan="2">Qty</td>

<td rowspan="2">Description</td> <td colspan="2">Price</td>

</tr>

<tr class="carttitle">

<td>Each</td> <td>Total</td>

</tr> <%

for item in @items product = item.product

-%>

<tr>

<td><%= item.quantity %></td>

5Which you can do if you want. You can delete the cookie file (on a Unix box it will be in a file whose name starts ruby_sess in your /tmp directory. Alternatively, look in your browser for a cookie from localhost called _session_id, and delete it.

ITERATION C1: CREATING A CAR T 85

Figure 8.3: On Our Way to a Presentable Cart

<td><%= h(product.title) %></td>

<td align="right"><%= item.unit_price %></td>

<td align="right"><%= item.unit_price * item.quantity %></td>

</tr> <% end %>

<tr>

<td colspan="3" align="right"><strong>Total:</strong></td> <td id="totalcell"><%= @cart.total_price %></td>

</tr> </table>

After a bit of CSS magic, our cart looks like Figure 8.3 .

Happy that we have something presentable, we call our customer over and show her the result of our morning’s work. She’s pleased—she can see the site starting to come together. However, she’s also troubled, having just read an article in the trade press on the way e-commerce sites are being attacked and compromised daily. She read that one kind of attack involves feeding requests with bad parameters into web applications, hoping to expose bugs and security flaws. She noticed that the link to add an item to our cart looks like store/add_to_cart/nnn, where nnn is our internal product id. Feeling malicious, she manually types this request into a browser, giving it a product id of "wibble." She’s not impressed when our application displays the page in Figure 8.4, on the following page. So it looks as if our next iteration will be spent making the application more resilient.

Figure 8.4: Our Application Spills Its Guts

8.4 Iteration C2: Handling Errors

Looking at the page displayed in Figure 8.4, it’s apparent that our application threw an exception at line 8 of the store controller. That turns out to be the line

product = Product.find(params[:id])

If the product cannot be found, Active Record throws a RecordNotFound exception, which we clearly need to handle. The question arises—how?

We could just silently ignore it. From a security standpoint, this is probably the best move, as it gives no information to a potential attacker. However, it also means that should we ever have a bug in our code that generates bad product ids, our application will appear to the outside world to be unresponsive—no one will know there’s been an error.

Instead, we’ll take three actions when an exception is thrown. First, we’ll log the fact to an internal log file using Rails’ logger facility (described on page 186). Second, we’ll output a short message to the user (something along the lines of “Invalid product”). And third, we’ll redisplay the catalog page so they can continue to use our site.

The Flash!

As you may have guessed, Rails has a convenient way of dealing with errors and error reporting. It defines a structure called a flash. A flash is a bucket (actually closer to a Hash), into which you can store stuff as you process a request. The contents of the flash are available to the next request in this session before being deleted automatically. Typically the flash is used to collect error messages. For example, when our add_to_cart( ) action detects that it was passed an invalid product id, it can store that error message in the flash area and redirect to the index( ) action to redisplay the catalog. The view for the index action can extract the error and display it at the top of the catalog page. The flash information is accessible within the views by using the @flash instance variable.

Why couldn’t we just store the error in any old instance variable? Remember that a redirect is sent by our application to the browser, which then sends a new request back to our application. By the time we receive that request, our application has moved on—all the instance variables from previous requests are long gone. The flash data is stored in the session in order to make it available between requests.

Armed with all this background about flash data, we can now change our add_to_cart( ) method to intercept bad product ids and report on the problem.

product = Product.find(params[:id]) @cart = find_cart @cart.add_product(product)

redirect_to(:action => 'display_cart') rescue

logger.error("Attempt to access invalid product #{params[:id]}") flash[:notice] = 'Invalid product'

redirect_to(:action => 'index') end

The rescue clause intercepts the exception thrown by Product.find( ). In the handler we use the Rails logger to record the error, create a flash notice with an explanation, and redirect back to the catalog display. (Why redirect, rather than just display the catalog here? If we redirect, the user’s

browser will end up displaying a URL of http://.../store/index, rather than http://.../store/add_to_cart/wibble. We expose less of the application this way. We also prevent the user from retriggering the error by hitting the Reload button.)

With this code in place, we can rerun our customer’s problematic query. This time, when we explicitly enter

http://localhost:3000/store/add_to_cart/wibble

we don’t see a bunch of errors in the browser. Instead, the catalog page is displayed. If we look at the end of the log file (development.log in the log directory), we’ll see our message.6

Parameters: {"action"=>"add_to_cart", "id"=>"wibble", "controller"=>"store"} Product Load (0.000439) SELECT * FROM products WHERE id = 'wibble' LIMIT 1

Attempt to access invalid product wibble

Redirected to http://localhost:3000/store/

:: :

Rendering store/index within layouts/store Rendering layouts/store (200 OK)

Completed in 0.006420 (155 reqs/sec) | Rendering: 0.003720 (57%) | DB: 0.001650 (25%)

<head>

<title>Pragprog Books Online Store</title>

<%= stylesheet_link_tag "depot", :media => "all" %>

</head> <body>

<div id="banner">

<img src="/images/logo.png"/>

<%= @page_title || "Pragmatic Bookshelf" %>

</div>

<div id="columns"> <div id="side">

<a href="http://www....">Home</a><br />

<a href="http://www..../faq">Questions</a><br /> <a href="http://www..../news">News</a><br />

<a href="http://www..../contact">Contact</a><br />

</div>

<div id="main">

<% if @flash[:notice] -%>

<div id="notice"><%= @flash[:notice] %></div> <% end -%>

<%= @content_for_layout %>

</div> </div>

</body> </html>

This time, when we manually enter the invalid product code, we see the error reported at the top of the catalog page.

While we’re looking for ways in which a malicious user could confuse our application, we notice that the display_cart( ) action could be called directly from a browser when the cart is empty. This isn’t a big problem—it would just display an empty list and a zero total, but we could do better than that. We can use our flash facility followed by a redirect to display a nice notice at the top of the catalog page if the user tries to display an empty cart. We’ll modify the display_cart( ) method in the store controller.