带有ember-simple-auth和Devise的CSRF令牌session_store

Question

使用ember-simple-auth设计时，是否可以通过cookie_store实现Rails csrf？

这样的指南one总是停用Rails.application.config.session_store，根据我的理解，这不允许Rails跟踪导致Rails失去会话记录的csrf令牌。在尝试了许多解决方案后，包括：

1. require jquery_ujs关于Rails宣言。
2. Rails.application.config.session_store :disabled。
3. https://github.com/abuiles/rails-csrf。
4. Changing Ember.js附加CSRF的适配器。

最终结果仍然几乎相同：

如果protect_from_forgery设置为：exception而不是：null_session，则

无法验证CSRF令牌真实性，然后是已完成422无法处理的实体。

示例交易：

部分请求HEADER：

X-CSRF-Token:1vGIZ6MFV4kdJ0yYGFiDq54DV2RjEIaq57O05PSdNdLaqsXMzEGdQIOeSyAWG1bZ+dg7oI6I2xXaBABSOWQbrQ==

响应者HEADER

   HTTP/1.1 422 Unprocessable Entity
   Content-Type: text/plain; charset=utf-8
   X-Request-Id: 71e94632-ad98-4b3f-97fb-e274a2ec1c7e
   X-Runtime: 0.050747
   Content-Length: 74162

  The response also attaches the following:
  Session dump
  _csrf_token: "jFjdzKn/kodNnJM0DXLutMSsemidQxj7U/hrGmsD3DE="

来自 csrf分支的 rails-csrf 响应（分支已被删除）。

beforeModel() {
    return this.csrf.fetchToken();
},

Partial dump of the return statement:

_result: Object
param: "authenticity_token"
token: "1vGIZ6MFV4kdJ0yYGFiDq54DV2RjEIaq57O05PSdNdLaqsXMzEGdQIOeSyAWG1bZ+dg7oI6I2xXaBABSOWQbrQ=="

根据我的理解，所有这些尝试的解决方案都有共同的根：session_store被禁用...

Answer 1

更新！

在了解了有关CSRF保护和Ember-Cli-Rails的更多信息后，下面的答案本质上是错误的。

这里的想法是拥有两个存储：一个基于cookie的存储，仅用于由Rails维护的csrf令牌，以及一个由Ember-simple-auth维护的localStorage，其中正在使用用户真实性令牌，电子邮件和id自定义会话时的关注SessionAccount继承这些值并在设置可用于整个Ember.js的用户之前对服务器进行验证。

SessionAccount的验证是为了检测对localStorage的任何篡改。每当SessionAccount查询localStorage（例如页面重新加载）时，验证就会发生，因为它通过令牌模型（令牌，电子邮件和ID）与服务器通信。服务器通过TokenSerializer以200或404响应，TokenSerializer仅呈现电子邮件或验证错误，因此除非用户通过需要电子邮件和密码的登录表单登录，否则不会透露前端以查看其他authentication_tokens。

根据我的理解，这种方法中的弱点不容易受到如此容易破解的影响，除非：

• 有人入侵服务器并获取数据库内容。虽然密码是盐渍的，但任何拥有数据库转储的人都可以将localStorage令牌，电子邮件和ID更改为他们想要模拟的人，并且服务器验证将起作用。但是，这可以通过每24小时（或任何其他时间帧）更改未登录用户的身份验证令牌的工作人员来最小化。代码示例部分当前没有工作者，因为我还没有了解它们。 / LI>
• 有人知道他们想要破解的人的密码和电子邮件......目前我无能为力。
• 有人拦截通过JSON API传递的数据。强大的SSL实施应该做得很好。
• 如果您的sessionAccount包含is_Admin行中的内容，则该令牌可以与POST请求一起发送给仅管理员请求，以便进一步验证后端，因为您永远不会信任该前端。
• 别的什么？那些是我所知道的。

现在进入实用的方法：

1. 设置 {strong> session_store.db 上的Rails.application.config.session_store :csrf_cookie_store, key: '_xxxxx_id', httponly: false。
2. 在lib下创建csrf_cookie_store，并在带有require 'csrf_cookie_store'的application.rb上要求它。
3. 在 application.rb 上设置protect_from_forgery with: :exception。
4. 创建TokenController以处理验证。
5. TokenSerializer以便只发送回电子邮件。
6. 更新您的Devise Session controller以在登录时更改令牌，并在会话销毁时跳过真实性令牌验证。
7. 检查您的routes是否仅创建令牌并拥有自定义设计会话。
8. 创建Ember.js Token Model
9. 将您的SessionAccount与我创建的内容相匹配。
10. 更新您的Devise Authenticator，以便在会话失效时向服务器发送删除请求。
11. 测试一下。