The way that occurs to you first is to fix all the controllers individually. That is, add the “before_filter…” line to bank_controller.rb, healer_controller.rb, etc. But that has two problems with it. One is that it is repeating ourselves and Rails is always trying to teach you “Don’t Repeat Yourself” and the other problem is that it is error prone. It’s too easy to add a new controller for some new pages and forget to put security on them.

What we want in all cases is for security to already be there and we just turn it off in those few cases where we don’t need it rather than having to remember to do so when we do need it.

So we’ll remove the “before_filter :login_required” line from the forest_controller.rb and move it instead to the application.rb file. Since all our other controllers inherit from this one controller, every method on all of them will be instantly protected. In fact, we’re now a little too protected, the user can no longer go to even the welcome page without logging in first.

In order to fix that, we’ll add an override to three controllers. The Welcome controller (welcome_controller.rb), the Users controller (users_controller.rb), and the Sessions controller (sessions_controller.rb):

skip_before_filter :login_required

With that in place we’ll skip the login requirement just for the pages related to those three controllers but the bank, healer, forest, and any other controller we add from now on will be protected from entry by users who haven’t logged in yet.

Authorization Is Not Authentication

I almost made this an extra credit item but it became too long and it’s a basic thing that most any game is going to have to deal with eventually. Authentication and authorization are not the same thing. All we have gotten so far from restful_authentication is just that, authentication. It lets someone sign up in the system and then verifies later via login name and password that the person trying to log in is a person the site has seen before and specifically which one it is.

Authorization is about permission to do things. Once I know who logged in, what is he or she allowed to do? Play the game, kick out duplicate accounts, end the game? restful_authentication has hooks built in which can be used with other plugins to manage complicated permission systems but you can also easily stick some simple testing in yourself. Let’s add a page which can only be accessed by a select user to demonstrate this.

> ruby script/generate controller Admin index

Update your new Admin controller (app/controllers/admin_controller.rb) to add the authorized? function you see below:

class AdminController < ApplicationController
  def index
  end
 
  private
 
  # By adding a function named "authorized?" and performing a test in it
  # we use one of the hooks provided by restful_authentication.
  def authorized?
    current_user.login == "Admin"
  end  
end

Now try to go to the admin page (http://localhost:3000/admin). If you create a user named “Admin” then you will be able to access the page when you are that user. Any other user will fail and will be automatically redirected.

> ruby script/generate controller Healer index

We add a new healing function to the User model (app/models/user.rb):

def heal(amount)
  if (amount < 0 or amount > self.gold)
    amount = self.gold
  end
 
  if (amount > (self.max_hp - self.cur_hp))
    amount = self.max_hp - self.cur_hp
  end
 
  self.gold -= amount
  self.cur_hp += amount
  self.save
 
  amount
end

The contents of app/views/healer/index.html.erb:

<p>Welcome to the healer. You currently have 
<strong><%= current_user.cur_hp %></strong> HP out of a maximum of 
<strong><%= current_user.max_hp %></strong>.</p>
 
<p>You have <strong><%= current_user.gold%></strong> gold to heal yourself with, 
and it will cost you <strong>1 gold per HP healed</strong> to heal yourself.</p>
 
<% form_tag('/healer/do_some_healing', :method => :post) do %>
  <%= text_field_tag 'amount' %>
  <%= submit_tag 'Heal Me'%>
<% end %>
<p><%= link_to "Home", :controller => 'welcome' %></p>
 
<script type="text/javascript">
  window.onload = function() {
    document.getElementById('amount').focus();
  }
</script>

And, as always, we pull together our model changes and the view in the controller (app/controllers/healer_controller.rb):

class HealerController < ApplicationController
  def index
  end
 
  def do_some_healing
    # The amount we actually healed might be different than the amount requested
    # due to a variety of factors (i.e. they didn't need that much healing, they
    # didn't have enough gold, etc.) so we record the amount they actually healed
    # which comes back from the method call.
    amount = current_user.heal(params[:amount].to_i)
 
    flash[:notice] = "You have been healed for #{amount} HP."
    render :action => "index"
  end
end

As with the bank and the forest, our finishing touch is to add a link to the destination on the welcome page (app/views/welcome/index.html.erb):

<%= link_to "The Healer", :controller => "healer" %>

In order to add a bank to the game we know we need a new page to handle the user interaction. So, does that go into an existing controller? At present I think the answer is no, we’ll generate a new controller just for the bank (like we did for the forest):

> ruby script/generate controller Bank index

In addition to something to handle the UI, we also need someplace to keep track of the money in the bank so we’ll add a new field for that to the user:

> ruby script/generate migration AddBankgcToUser bankgc:integer

The migration we just generated will handle adding the new field to all existing users and any new ones that join, but we need to edit it to add a default value of zero for the field:

add_column :users, :bankgc, :integer, :default => 0

Be sure to run the migration to change the database table:

> rake db:migrate

Now we need some functionality to let us deposit money into the “bank” and withdraw it again later. To do that we’ll add two new functions into our User model (app/models/user.rb):

def deposit(amount)
  if (amount < 0 or amount > self.gold)
    amount = self.gold
  end
 
  self.bankgc += amount
  self.gold -= amount
  self.save
 
  amount
end
 
def withdraw(amount)
  if (amount < 0 or amount > self.bankgc)
    amount = self.bankgc
  end
 
  self.bankgc -= amount
  self.gold += amount
  self.save
 
  amount
end

One of the only things new and worth noting here is that the revised amount is referenced on the last line of each function. In Ruby that makes it a return value so we can see exactly how much really was moved when the user specifies a ridiculous value (i.e. attempting to withdraw 20000 with only 5 in the bank). We’ll use that in the controller code later.

Next we need to fill in the view. It will both inform the user of how much money he/she has in the bank and in hand and take input via a form and buttons to indicate which way the transfer should occur. Here’s the code for the view (app/views/bank/index.html.erb):

<p>Welcome to the bank. You currently have 
<strong><%= @current_user.bankgc %></strong> gold in the bank, 
and <strong><%= @current_user.gold %></strong> gold in hand.</p>
 
<% form_tag('/bank/do_some_banking', :method => :post) do %>
  <%= text_field_tag 'amount' %><br/>
  <%= submit_tag 'Deposit' %><%= submit_tag 'Withdraw' %>
<% end %>
<p><%= link_to 'Home', :controller => 'welcome' %></p>
 
<script type="text/javascript">
  window.onload = function() {
    document.getElementById('amount').focus();
  }
</script>

One thing slightly different about this form is that we have one form with multiple different submit buttons. We can differentiate between them when the controller gets the submitted results of the form so we know what to do. Another thing to note about this form is that it isn’t a form_for, but instead a form_tag. form_for makes it easy to have a set of fields and populate them from a model object, then gather up the results and put them into a hash which can be assigned directly back to the same type of model object to create a new one or edit the values in it. But we don’t have a model for this page, we just one one value (a number in this case) returned to the controller so form_tag is what makes sense.

Lastly we will pull all these pieces together in the controller. We’ll use the hash of parameters created from the user filling in the form and figure out which of the new methods on the user model to call. As before, the model is doing the real work, the view is taking the user’s input, and the controller is gluing the two together. Here’s the code for the Bank controller we generated earlier (app/controllers/bank_controller.rb):

class BankController < ApplicationController
  def index
    current_user
  end
 
  def do_some_banking
    if params[:commit] == "Deposit"
      amount = current_user.deposit(params[:amount].to_i)
 
      flash[:notice] = "You deposited #{amount} gold into your bank account. Your total in the bank is now #{@current_user.bankgc}."
    else
      amount = current_user.withdraw(params[:amount].to_i)
 
      flash[:notice] = "You withdraw #{amount} gold from your bank account. Your total gold in hand is now #{@current_user.gold}."
    end
 
    render :action => "index"
  end
end

The code consists of getting the current user and then performing actions on that user. The code we added to the model gives us the new features we need and the view got the values into the hash so we can find them. The controller is only responsible for getting the user’s input out of the hash and passing it on to the correct functions in the model. It also acts as a translator to take responses from the model and turn them into messages which can be displayed by the view. As I mentioned before, we can look in the hash coming from the view and the value of the params[:commit] tells the code whether the user clicked on the “Deposit” or “Withdraw” button.

Our final touch is adding the bank as a destination to the welcome page (for a logged in user). Add this below the corresponding link to the forest in app/views/welcome/index.html.erb:

<%= link_to "The Bank", :controller => "bank" %>

Extra Credit

1. “rake –tasks” tells you about all the commands rake supports. We’ve used “rake db:migrate” many times but there are actually several rake functions to manipulate the database. In particular I’ll point out “rake db:migrate:redo”. I used it while working on this particular entry because the first time I built it I forgot to set a default value for bankgc in the user, so I went back and added the default value and used the “rake db:migrate:redo” to undo the last migration (it calls the self.down in the migration) and then run the migration again to correct the error. Then I had the new field on each user and it had a default value of zero for all of them.
2. form_for and form_tag are both helper functions. Helper functions are Rails methods designed to help you generate HTML with less pain, and in the case of form_for, generate HTML that follows certain patterns (e.g. the naming of fields in the form) so that it will work together with code to make some activity simpler.