相关疑难解决方法(0)

我用AJAX从视图向控制器发送数据我得到了这个错误:

警告:无法验证CSRF令牌的真实性

我想我必须发送带有数据的令牌.

有谁知道我该怎么做？

编辑:我的解决方案

我通过将以下代码放在AJAX帖子中来完成此操作:

headers: {
  'X-Transaction': 'POST Example',
  'X-CSRF-Token': $('meta[name="csrf-token"]').attr('content')
},

我有一个rails应用程序,为i​​Phone应用程序提供一些api.我希望能够简单地在资源上发布,而无需考虑获取正确的csrf令牌.我尝试了一些我在stackoverflow中看到的方法,但似乎它们不再适用于rails 3.感谢您帮助我.

这个问题已被问过几次,但我仍然不明白:

当我读到关于的答案

没有'Access-Control-Allow-Origin'标题

问题,它说应该在请求的服务器上设置一个设置,以允许跨域:add_header 'Access-Control-Allow-Origin' '*';.

但是,请告诉我为什么当从邮递员(这是一个客户)询问时,它的工作就像一个魅力,我收到了所请求服务器的回复？

谢谢

早在2011年2月,Rails 就更改为要求所有非GET请求的CSRF令牌,甚至是API端点的请求.我理解为什么这是浏览器请求的重要更改的解释,但该博客文章没有提供有关API应如何处理更改的任何建议.

我对某些操作禁用CSRF保护不感兴趣.

API如何应对这种变化？期望API客户端向API发出GET请求以获取CSRF令牌,然后在该会话期间的每个请求中包含该令牌吗？

似乎令牌不会从一个POST更改为另一个POST.假设令牌在会话期间不会改变是否安全？

我不喜欢会话到期时的额外错误处理,但我认为它比在每个POST/PUT/DELETE请求之前获取令牌更好.

我正在使用Rails进行单页应用程序.登录和注销时,使用ajax调用Devise控制器.我得到的问题是,当我1)登录2)退出然后再次登录不起作用.

我认为它与CSRF令牌有关,当我退出时它会被重置(虽然它不应该是afaik),并且因为它是单页,旧的CSRF令牌正在xhr请求中发送,从而重置会话.

更具体地说,这是工作流程:

1. 登入
2. 登出
3. 登录(成功201.但是WARNING: Can't verify CSRF token authenticity在服务器日志中打印)
4. 随后的ajax请求未通过401未授权
5. 刷新网站(此时,页眉中的CSRF更改为其他内容)
6. 我可以登录,它可以工作,直到我尝试退出并重新登录.

任何线索非常感谢!如果我可以添加更多详细信息,请与我们联系.

我注意到如果你使用无效的CSRF令牌发帖,rails/devise会自动注销你.

我有一个不刷新页面的应用程序,用户长时间坐在实时页面上.每隔一段时间,用户就会被踢出局.我想知道CSRF令牌是否到期,使其无效.

这就是为什么我要学习,Rails CSRF令牌到期了吗？某个地方有时间吗？

谢谢

在阅读了CSRF保护在Rails中的工作原理后，我尝试通过执行以下操作来触发CSRF保护：

注意：我们正在使用基于cookie的会话。

1. 访问登录页面。检查meta => abc123中的CSRF令牌
2. 打开第二个浏览器选项卡，然后访问相同的登录页面。meta中的CSRF令牌不同=> def456
3. 返回第一个标签。
4. 提交登录凭据。

我期望这会失败，因为第二个选项卡生成了一个新的，不同的CSRF令牌。提交登录表单时，提交给服务器的令牌不应该是旧的，陈旧的令牌吗？

但是，这确实有效：

1. 访问登录页面。检查meta => abc123中的CSRF令牌
2. 打开第二个浏览器选项卡，然后访问相同的登录页面。meta中的CSRF令牌不同=> def456
3. 返回第一个标签。
4. 提交登录凭据。
5. 注销（清除会话）
6. 转到第二个选项卡，然后提交登录。

在这种情况下，我得到一个InvalidAuthenticityToken异常。为什么？