Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Add some information about handle_unverified_request to guides.

  • Loading branch information...
commit 7d8474e20a7c3ee720c2659e52d1862dcd8b368d 1 parent ef4b3ee
Erich Menge authored
Showing with 11 additions and 0 deletions.
  1. +11 −0 guides/source/security.textile
11 guides/source/security.textile
@@ -236,6 +236,17 @@ protect_from_forgery :secret => "123456789012345678901234567890..."
This will automatically include a security token, calculated from the current session and the server-side secret, in all forms and Ajax requests generated by Rails. You won't need the secret, if you use CookieStorage as session storage. If the security token doesn't match what was expected, the session will be reset. *Note:* In Rails versions prior to 3.0.4, this raised an <tt>ActionController::InvalidAuthenticityToken</tt> error.
+It is common to use persistent cookies to store user information, with +cookies.permanent+ for example. In this case, the cookies will not be cleared and the out of the box CSRF protection will not be effective. If you are using a different cookie store than the session for this information, you must handle what to do with it yourself:
+def handle_unverified_request
+ super
+ sign_out_user # Example method that will destroy the user cookies.
+The above method could be placed in the +ApplicationController+ and will be called when a CSRF token is not present on a POST request.
Note that _(highlight)cross-site scripting (XSS) vulnerabilities bypass all CSRF protections_. XSS gives the attacker access to all elements on a page, so he can read the CSRF security token from a form or directly submit the form. Read <a href="#cross-site-scripting-xss">more about XSS</a> later.
h3. Redirection and Files

0 comments on commit 7d8474e

Please sign in to comment.
Something went wrong with that request. Please try again.