aboutsummaryrefslogtreecommitdiffstats
path: root/railties
diff options
context:
space:
mode:
authorVijay Dev <vijaydev.cse@gmail.com>2011-05-02 17:31:00 +0530
committerVijay Dev <vijaydev.cse@gmail.com>2011-05-02 17:31:00 +0530
commit527036ebd106fdb4d5890f00f2576a99c57b1514 (patch)
treea07796afab3019dd99cf3234f0e17d562f9e42b0 /railties
parent9fa080e703362876b5afe9a7627bf3ffb6fa131e (diff)
downloadrails-527036ebd106fdb4d5890f00f2576a99c57b1514.tar.gz
rails-527036ebd106fdb4d5890f00f2576a99c57b1514.tar.bz2
rails-527036ebd106fdb4d5890f00f2576a99c57b1514.zip
removed verify docs (feature removed in Rails3)
Diffstat (limited to 'railties')
-rw-r--r--railties/guides/source/action_controller_overview.textile39
1 files changed, 0 insertions, 39 deletions
diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index f8b586c151..3a1a4ee66e 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -488,45 +488,6 @@ end
Again, this is not an ideal example for this filter, because it's not run in the scope of the controller but gets the controller passed as an argument. The filter class has a class method +filter+ which gets run before or after the action, depending on if it's a before or after filter. Classes used as around filters can also use the same +filter+ method, which will get run in the same way. The method must +yield+ to execute the action. Alternatively, it can have both a +before+ and an +after+ method that are run before and after the action.
-h3. 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.
-
-Here's an example of using verification to make sure the user supplies a username and a password in order to log in:
-
-<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
-</ruby>
-
-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:
-
-<ruby>
-class LoginsController < ApplicationController
- verify :params => [:username, :password],
- :render => {:action => "new"},
- :add_flash => {
- :error => "Username and password required to log in"
- },
- :only => :create # Run only for the "create" action
-end
-</ruby>
-
h3. Request Forgery Protection
Cross-site request forgery is a type of attack in which a site tricks a user into making requests on another site, possibly adding, modifying or deleting data on that site without the user's knowledge or permission.