Add some information about handle_unverified_request to guides.

1 files changed, 11 insertions, 0 deletions

diff --git a/guides/source/security.textile b/guides/source/security.textile
index ac55d60368..14038a9bcd 100644
--- a/guides/source/security.textile
+++ b/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:
+
+<ruby>
+def handle_unverified_request
+    super
+    sign_out_user # Example method that will destroy the user cookies.
+end
+</ruby>
+
+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