aboutsummaryrefslogtreecommitdiffstats
path: root/railties/doc/guides/source/actioncontroller_basics/verification.txt
blob: a4522a010290a2cd91b2a0c5117fa56f49a44c27 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
== Verification ==

Verifications make sure certain criteria are met in order for a controller or action to run. They can specify that a certain key (or several keys in the form of an array) is present in the `params`, `session` or `flash` hashes or that a certain HTTP method was used or that the request was made using XMLHTTPRequest (Ajax). The default action taken when these criteria are not met is to render a 400 Bad Request response, but you can customize this by specifying a redirect URL or rendering something else and you can also add flash messages and HTTP headers to the response. It is described in the link:http://api.rubyonrails.org/classes/ActionController/Verification/ClassMethods.html[API documentation] as "essentially a special kind of before_filter".

Here's an example of using verification to make sure the user supplies a username and a password in order to log in:

[source, ruby]
---------------------------------------
class LoginsController < ApplicationController

  verify :params => [:username, :password],
         :render => {:action => "new"},
         :add_flash => {:error => "Username and password required to log in"}

  def create
    @user = User.authenticate(params[:username], params[:password])
    if @user
      flash[:notice] = "You're logged in"
      redirect_to root_url
    else
      render :action => "new"
    end
  end

end
---------------------------------------

Now the `create` action won't run unless the "username" and "password" parameters are present, and if they're not, an error message will be added to the flash and the `new` action will be rendered. But there's something rather important missing from the verification above: It will be used for *every* action in LoginsController, which is not what we want. You can limit which actions it will be used for with the `:only` and `:except` options just like a filter:

[source, ruby]
---------------------------------------
class LoginsController < ApplicationController

  verify :params => [:username, :password],
         :render => {:action => "new"},
         :add_flash => {:error => "Username and password required to log in"},
         :only => :create # Only run this verification for the "create" action

end
---------------------------------------