我正在遇到有关 Rails 中的 Authenticity Token 的一些问题，因为我现在已经多次了。
但我真的不想只是解决这个问题而继续下去。我真的很想了解真实性令牌。那么，我的问题是，您是否有关于此主题的完整信息来源，或者您是否会花时间在此详细解释？
怎么了
当用户查看表单以创建，更新或销毁资源时，Rails 应用程序会创建一个随机的authenticity_token ，将此令牌存储在会话中，并将其放在表单中的隐藏字段中。当用户提交表单时，Rails 会查找authenticity_token ，将其与存储在会话中的那个进行比较，如果匹配，则允许继续请求。
为什么会这样
由于真实性令牌存储在会话中，因此客户端无法知道其值。这可以防止人们在不查看该应用程序本身内的表单的情况下向 Rails 应用程序提交表单。想象一下，您正在使用服务 A，您登录该服务，一切正常。现在想象一下你去使用服务 B，你看到了你喜欢的图片，并按下图片来查看更大尺寸的图片。现在，如果服务 B 上有一些恶意代码，它可能会向服务 A（您已登录）发送请求，并要求删除您的帐户，方法是向http://serviceA.com/close_account发送请求。这就是所谓的CSRF（Cross Site Request Forgery） 。
如果服务 A 使用真实性令牌，则此攻击向量不再适用，因为来自服务 B 的请求将不包含正确的真实性令牌，并且将不允许继续。
API 文档描述了有关元标记的详细信息：
使用
protect_from_forgery方法打开 CSRF 保护，该方法检查令牌并在会话与预期不匹配时重置会话。默认情况下，会为新的 Rails 应用程序生成对此方法的调用。 token 参数默认名为authenticity_token。必须通过在 HTML 头中包含csrf_meta_tags，将此标记的名称和值添加到呈现表单的每个布局中。
笔记
请记住，Rails 只验证非幂等方法（POST，PUT / PATCH 和 DELETE）。不检查 GET 请求的真实性令牌。为什么？因为 GET 请求的 HTTP 规范状态是幂等，并在服务器不应该创建，改变或破坏资源，应该将请求幂等（如果您运行相同的命令多次，你应该每次都得到相同的结果）。
此外，真正的实现在开始时定义更复杂，确保更好的安全性。 Rails 不会为每个表单发出相同的存储令牌。它也不是每次都生成和存储不同的令牌。它在会话中生成并存储加密哈希，并发布新的加密令牌，每次呈现页面时，可以与存储的加密令牌进行匹配。请参阅request_forgery_protection.rb 。
教训
使用authenticity_token来保护您的非幂等方法（POST，PUT / PATCH 和 DELETE）。还要确保不允许任何可能修改服务器上资源的 GET 请求。
真品令牌旨在让您知道您的表单是从您的网站提交的。它是从运行它的机器生成的，具有唯一的标识符，只有您的机器可以知道，从而有助于防止跨站点请求伪造攻击。
如果您只是在使用 rails 拒绝访问 AJAX 脚本时遇到困难，可以使用
<%= form_authenticity_token %>在创建表单时生成正确的标记。
您可以在文档中阅读更多相关信息。
真实性令牌是跨站请求伪造（CSRF）的对策。你问什么是 CSRF？
这是攻击者可能在不知道会话令牌的情况下劫持会话的方式。
场景 ：
CSRF 解决方案 ：