mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
Merge pull request #31640 from gingerlime/patch-1
fixes #27157 CSRF protection documentation
This commit is contained in:
commit
5f9f39eb9c
1 changed files with 11 additions and 4 deletions
|
@ -17,7 +17,7 @@ module ActionController #:nodoc:
|
|||
# access. When a request reaches your application, \Rails verifies the received
|
||||
# token with the token in the session. All requests are checked except GET requests
|
||||
# as these should be idempotent. Keep in mind that all session-oriented requests
|
||||
# should be CSRF protected, including JavaScript and HTML requests.
|
||||
# are CSRF protected by default, including JavaScript and HTML requests.
|
||||
#
|
||||
# Since HTML and JavaScript requests are typically made from the browser, we
|
||||
# need to ensure to verify request authenticity for the web browser. We can
|
||||
|
@ -30,16 +30,23 @@ module ActionController #:nodoc:
|
|||
# URL on your site. When your JavaScript response loads on their site, it executes.
|
||||
# With carefully crafted JavaScript on their end, sensitive data in your JavaScript
|
||||
# response may be extracted. To prevent this, only XmlHttpRequest (known as XHR or
|
||||
# Ajax) requests are allowed to make GET requests for JavaScript responses.
|
||||
# Ajax) requests are allowed to make requests for JavaScript responses.
|
||||
#
|
||||
# It's important to remember that XML or JSON requests are also affected and if
|
||||
# you're building an API you should change forgery protection method in
|
||||
# It's important to remember that XML or JSON requests are also checked by default. If
|
||||
# you're building an API or an SPA you could change forgery protection method in
|
||||
# <tt>ApplicationController</tt> (by default: <tt>:exception</tt>):
|
||||
#
|
||||
# class ApplicationController < ActionController::Base
|
||||
# protect_from_forgery unless: -> { request.format.json? }
|
||||
# end
|
||||
#
|
||||
# It is generally safe to exclude XHR requests from CSRF protection
|
||||
# (like the code snippet above does), because XHR requests can only be made from
|
||||
# the same origin. Note however that any cross-origin third party domain
|
||||
# allowed via {CORS}[https://en.wikipedia.org/wiki/Cross-origin_resource_sharing]
|
||||
# will also be able to create XHR requests. Be sure to check your
|
||||
# CORS whitelist before disabling forgery protection for XHR.
|
||||
#
|
||||
# CSRF protection is turned on with the <tt>protect_from_forgery</tt> method.
|
||||
# By default <tt>protect_from_forgery</tt> protects your session with
|
||||
# <tt>:null_session</tt> method, which provides an empty session
|
||||
|
|
Loading…
Reference in a new issue