在 rails 3.2 + devise 2.0 之后设计列confirmed_at 不再更新答案

【问题标题】：Devise column confirmed_at no longer updates after rails 3.2 + devise 2.0在 rails 3.2 + devise 2.0 之后设计列confirmed_at 不再更新
【发布时间】：2012-02-07 22:17:18
【问题描述】：

升级到 rails 3.2 并设计 2.0 后并单击通过电子邮件发送的确认链接或从开发中的控制台复制的确认链接，confirmed_at 列不会更新。所以结果就是无法登录。

什么方法可以解决这个问题，因为日志中没有出现任何内容，可访问的属性已确认_at 包括在内，因此该列应该是可更新的。

【问题讨论】：

我也升级到这个配置（可以确认），它工作正常。发生的事情是（一方面）邮件发送正确，当您单击链接时，您将被重定向到您的服务器并显示“欢迎 abc@example.com”，但数据库上的列未更新？
是的，这是正确的，确认链接已发送，单击时显示“已确认”，并在下方显示“您必须在登录前确认”的警报，然后当登录相同的错误时，confirmed_at 列不是设置。
您可以从非常基本的调试开始，例如尝试使用 Rails 控制台手动更新 confirm_at。之后再次点击链接等，然后相应地更新问题。
您是否也自定义了 Devise，或者您正在使用它。
我创建了一个 rails vanilla 应用程序，它试图通过可确认的方式重现此问题，但我没有得到您发现的问题 (github.com/rodrigoflores/Devise-confirmed-at-test/blob/master/…)。你能贴一下日志吗？还是日志和它的工作一样？

标签： ruby-on-rails ruby-on-rails-3 ruby-on-rails-3.1 devise

【解决方案1】：

用于故障排除的几个轴。

一开始（很明显 :-) ）您已在用户模型中确认激活

devise : :confirmable

然后，检查您的数据库和模型中是否定义了以下列（如果您在 Mongoid 上，则类似，但类型不同）

## Confirmable
t.string   :confirmation_token
t.datetime :confirmed_at
t.datetime :confirmation_sent_at
# t.string   :unconfirmed_email # Only if using reconfirmable

最后（我不知道它是否适用于您并提出问题）但 2.0 中关于可确认性发生了变化

此外，一些配置选项被重命名或删除：

Devise.confirm_within 重命名为 Devise.allow_unconfirmed_access_for；

那么为刚刚创建的新用户提供 Rails 控制台是什么？

应该给出类似的东西

User.last
 => #<User .... email: "youremail@example.com", confirmation_token: "abch76UfqHBBxHw97123", confirmed_at: nil, confirmation_sent_at: 2012-02-10 11:06:41 UTC, unconfirmed_email: nil, ....>

并且你收到的链接（也可以手动复制粘贴到浏览器中，应该和上面的确认token类似）

<p><a href="http://localhost:5000/users/confirmation?confirmation_token=abch76UfqHBBxHw97123">Confirm my account</a></p>

控制台中的用户应相应修改

User.last
 => #<User .... email: "youremail@example.com", confirmation_token:nil, confirmed_at: confirmed_at: 2012-02-10 11:28:04 UTC, confirmation_sent_at: 2012-02-10 11:06:41 UTC, unconfirmed_email: nil, ....>

如果在浏览器中复制链接还是不行，能否复制日志的最后几行？

周围的人

20:36:51 web.1     | Started GET "/users/confirmation?confirmation_token=abch76UfqHBBxHw97123" for 127.0.0.1 at 2012-02-10 20:36:51 +0900
20:36:51 web.1     | [127.0.0.1] Processing by Devise::ConfirmationsController#show as HTML
20:36:51 web.1     |  [127.0.0.1]   Parameters: {"confirmation_token"=>"abch76UfqHBBxHw97123"}

【讨论】：

可以确认以上都是正确的。日志中的最后一部分虽然说明了一些奇怪的情况。开始 GET "/users/confirmation?confirmation_token=PAPe74HyVmRheFbaBAaw" for 127.0.0.1 at 2012-02-10 16:35:16 +0100 由 ConfirmationsController#show as HTML 参数处理：{"confirmation_token"=>"PAPe74HyVmRheFbaBAaw"} 用户负载(0.4ms) SELECT users.* FROM users WHERE users.confirmation_token = 'PAPe74HyVmRheFbaBAaw' LIMIT 1 (0.2ms) BEGIN (0.1ms) COMMIT Completed 401 Unauthorized in 15ms
我的意思是“在 15 毫秒内完成 401 未授权”，这似乎是 CanCan 的一些问题，我之前错过了日志的这些部分，所以我似乎需要设置 CanCan，以便我可以提交我猜是用户资源，有什么想法吗？

【解决方案2】：

（我把它移到了一个不同的答案，因为我认为它值得）

{"confirmation_token"=>"PAPe74HyVmRheFbaBAaw"} 用户负载 (0.4ms) SELECT users.* FROM users WHERE users.confirmation_token = 'PAPe74HyVmRheFbaBAaw' LIMIT 1 (0.2ms) BEGIN (0.1ms) COMMIT Completed 401 Unauthorized in 15ms

您是否与 CanCan 一起使用？那是一个 Cancan 配置问题！如果您删除 CanCan，它可能会起作用:-)。不过，CanCan Wiki 中有一个针对这种情况的优雅解决方案。

将以下内容放入您的 ApplicationController

check_authorization :unless => :devise_controller?

https://github.com/ryanb/cancan/wiki/Ensure-Authorization

有条件地检查授权

从 CanCan 1.6 开始，check_authorization 方法支持 :if 和 :unless 选项。任何一个都将方法名称作为符号。将调用此方法以确定是否将执行授权检查。这使得在所有 Devise 控制器上跳过此检查变得非常容易，因为它们提供了 devise_controller?方法。

class ApplicationController < ActionController::Base
  check_authorization :unless => :devise_controller?  
end

【讨论】：

这似乎确实是要走的路，唯一的问题是添加此代码时“此操作未通过 check_authorization，因为它没有 authorize_resource。添加 skip_authorization_check 以绕过此检查。”
您是同时添加了Cancan还是之前使用过？你用的是什么版本？ rails g cancan:ability 为您完成所需的最少生成（基本上添加了一个能力.rb 文件）。
这个错误很“奇怪”，从某种意义上说，将:unless => :devise_controller? 等同于将skip_authorization_check 添加到gem 的默认设计控制器中。（它需要重新启动服务器）您是否正在为某些设计操作定义特殊控制器？
如果你 rake routes，这是控制器 cancan 抱怨 user_confirmation POST (/:locale)/users/confirmation(.:format) devise/confirmations#create。由于此控制器是 class Devise::ConfirmationsController < DeviseController，因此跳过检查
这可能会导致问题是的，我有一个使用设计控制器的自定义确认控制器。我应该如何解决这个问题？谢谢！