设计数据库迁移 - Ruby on Rails答案

【问题标题】：Devise Database Migration - Ruby on Rails设计数据库迁移 - Ruby on Rails
【发布时间】：2016-07-05 17:06:30
【问题描述】：

我有一个 Ruby on Rails (4.2.1) 应用程序，它使用 Devise (3.5.1) 对用户进行身份验证，我们正在 Rails (5.0.0) 中重建这个应用程序，我们正在使用 Devise (4.2.0)。当我将用户表从旧应用程序复制到新应用程序时会出现问题，然后在新应用程序中我无法使用旧数据登录。在 devise.rb 初始化程序中，我在两个应用程序中都使用了相同的 secret_key，所以不知道为什么我不能使用旧数据登录到新应用程序，有什么想法吗？

【问题讨论】：

有任何错误信息可以帮助我们吗？
当我尝试使用旧的电子邮件/密码登录时，我得到的只是“无效的电子邮件或密码”。来自设计的消息。
您的应用程序仅处于生产或开发阶段吗？您可以向每个用户发送重置令牌吗？
我首先在开发中测试它，是的，我可以将 reset_password_token 发送给每个用户，但我希望用户可以在新应用发布后正常登录且无需更改密码
您是否检查过您输入的密码是否等于存储的哈希密码（您可以做到）我敢打赌它不是。我的猜测是设计了内置程序来防止这种情况发生。重置您的用户密码并使用 devise 让他们在点击链接登录时更改密码。

标签： ruby-on-rails ruby devise

【解决方案1】：

首先，使用rails console 确保问题与密码有关，而不是应用程序 - 即您的用户模型的valid_password? 调用将因密码正确而失败。

Devise 默认使用this 方法生成密码哈希：

def self.digest(klass, password)
  if klass.pepper.present?
    password = "#{password}#{klass.pepper}"
  end
  ::BCrypt::Password.create(password, cost: klass.stretches).to_s
end

它使用klass.pepper 添加到您的密码（如果存在）。这里的 klass 将是您的模型（例如用户），可以是 configured 以使用胡椒：

除了 :stretches，你还可以定义 :pepper, :encryptor, :confirm_within, :remember_for, :timeout_in, :unlock_in 等选项。

cost 是新密码存储的盐生成复杂度，因此应该只影响新哈希的生成，不会影响对之前生成的密码的验证。

Devise 使用此方法将输入密码与存储的哈希值进行比较：

   def self.compare(klass, hashed_password, password)
      return false if hashed_password.blank?
      bcrypt   = ::BCrypt::Password.new(hashed_password)
      if klass.pepper.present?
        password = "#{password}#{klass.pepper}"
      end
      password = ::BCrypt::Engine.hash_secret(password, bcrypt.salt)
      Devise.secure_compare(password, hashed_password)
    end

只需在您的两个应用程序版本中调试它，即可查看此方法中的哪些输入参数可能不同，例如如果您为您的模型定义了不同的辣椒，bcrypt.salt 在您的两个应用程序中对于相同的 hashed_value 是不同的。

至于从现有存储的散列密码中提取盐的位置，实际上是simple。存储的字符串被$符号简单分割：

# call-seq:
#   split_hash(raw_hash) -> version, cost, salt, hash
#
# Splits +h+ into version, cost, salt, and hash and returns them in that order.
def split_hash(h)
  _, v, c, mash = h.split('$')
  return v.to_str, c.to_i, h[0, 29].to_str, mash[-31, 31].to_str
end

【讨论】：