3

我有一个使用 Devise 3.2.2 的 Rails 4 应用程序:confirmable，并且遇到了发送无效确认令牌的问题，但只是第一次。重新发送确认令牌后，该链接有效。

相关路线：

devise_for :users, skip: [:sessions, :passwords, :confirmations, :unlocks, :registrations, :invitations]
as :user do
  ...
  # joining
  get   '/register' => 'devise/registrations#new',    as: 'new_user_registration'
  post  '/register' => 'devise/registrations#create', as: 'user_registration'
  ...
end

...以及有问题的邮件模板：

<p>Welcome <%= @email %>!</p>

<p>You can confirm your account email through the link below:</p>

<p><%= link_to 'Confirm my account', confirmation_url(@resource, :confirmation_token => @token) %></p>

据我所知，一切都是相当标准的票价，而且它只在最初创建而不是重新发送时失败的事实相当令人困惑。

- 更新 -

单击链接时，我在开发日志中得到以下信息：

Started GET "/account/confirm?confirmation_token=3bQP-EvYJPv74s9AMz63" for 127.0.0.1 at 2014-02-07 12:26:10 -0500
Processing by Users::ConfirmationsController#show as HTML
  Parameters: {"confirmation_token"=>"3bQP-EvYJPv74s9AMz63"}
  User Load (0.4ms)  SELECT "users".* FROM "users" WHERE "users"."confirmation_token" = 'e191b48746f15014beb32073f08de3c7aa13a2282216f089fa71d083901b3dca' ORDER BY "users"."id" ASC LIMIT 1
  Rendered devise/shared/_links.slim (1.2ms)
  Rendered devise/confirmations/new.html.slim within layouts/devise (7.0ms)
  Rendered layouts/_jquery.slim (1.0ms)
Completed 200 OK in 32ms (Views: 23.4ms | ActiveRecord: 0.4ms)

引用的控制器是：

class Users::ConfirmationsController < Devise::ConfirmationsController

  protected

  def after_confirmation_path_for(resource_name, resource)
    if signed_in?
      signed_in_root_path(resource)
    else
      new_session_path(resource_name, email: resource.email)
    end
  end

end

-- 更新 2 --

以下是整个注册过程的日志要点： https ://gist.github.com/jbender/bbe079c2dd3fa2d1e664

4

2 回答 2

6

看起来有些东西会导致您的用户在注册create操作完成之前立即更新和重新保存（包括生成新的确认令牌）。看看你的要点：

  • 第 5 行显示了使用电子邮件地址对现有用户进行设计检查
  • 第 6 行显示设计检查它刚刚生成的确认令牌是否已经存在于其他用户（显然它们需要是唯一的）
  • 第 9 行显示了插入数据库的新用户记录
  • 然后第 11 行看起来 devise 刚刚生成了一个新的确认令牌，并且正在检查这个新令牌是否已经在使用中。
  • 然后第 14 行显示正在保存的更新用户详细信息，包括这个新的确认令牌。我注意到第 9 行的初始插入中没有一个 tos_accepted_at 字段。 unconfirmed_email 字段也已设置，confirmation_sent_at 字段比第 9 行中保存的字段晚 1 秒；这可能只是由于正常的 :confirmable 行为，尽管我很惊讶设计没有发现电子邮件地址与现有（未经确认的）电子邮件地址相同并且不打扰的事实。

问题是为什么用户被保存了两次？看起来您添加了一个 tos_accepted_at 属性。是否有一些代码（后过滤器？）重新保存用户，包括此属性以及所有其他属性，然后再次触发设计的可确认逻辑？说到这一点，我最感兴趣的是，它并没有立即导致发送第二封电子邮件（带有有效的确认令牌），因为 Confirmation_sent_at 时间戳发生了变化。

我注意到，从其他 INSERT 来看，也有一些版本跟踪正在进行，尽管看起来这不会造成干扰。

作为额外的健全性检查，如果您可以使用 Rails 控制台对您期望的确认令牌进行加密，您会发现加密版本与您的要点第 6 行的版本匹配，然后在 db 中覆盖第 9 行。我无法尝试此操作，因为它取决于您的 rails 密码（请参阅 devise/toekn_generator.rb 中的 Devise::TokenGenerator）。无论如何，没有必要，但会确认原始确认令牌永远不会起作用。

我认为重新发送有效，因为这只是正常情况（没有双重保存，没有额外的 tos_accepted_at 字段等）

更新

正如评论中所讨论的，问题确实是 tos_accepted_at 属性。它正在回调update_attribute()中使用更新。after_create由于有点不清楚的原因，这似乎弄脏了所有属性，所以它们也都被保存了（update_attribute如果它们是脏的，也会保存所有其他属性）并设计生成一个新的确认令牌作为此过程的一部分（尽管我们不要认为它应该有，因为电子邮件地址实际上并没有改变！）。更改将更新保存tos_accepted_at到before_save过滤器的过滤器，而不是after_create通过确保用户只保存一次来避免问题，因为before_save显然发生在第一次保存之前，而不是after_create在将用户插入数据库的保存之后当然发生。

于 2014-02-20T19:28:59.953 回答
-1

根据路由文件，我假设您已经覆盖了注册控制器。
我的预感是您在您的注册#create 操作中做错了一些事情。具体来说，confirmation_token 在创建时没有正确存储在用户记录中。

我的理论是：

  1. Confirmable.rb的第 278 行返回 false，因为第 277 行没有找到具有所提供令牌的用户，因为它没有正确存储。因此，277 创建了一个新的用户记录，然后 278 返回false。

  2. 当您完成重新发送过程时，整个令牌生成/存储过程会再次完成 la confirmable.rb和 confirms#create in confirms_controller.rb。这修复了registrations#create中丢失的存储步骤。

您能否在初始创建时验证 Confirmation_token 是否正确存储在您的用户模型上？

于 2014-02-07T18:31:01.243 回答