Rails身份验证-当*不*使用设计时的潜在陷阱

Question

我正在权衡是使用我自己的身份验证系统(就像优秀的Railscast)还是使用设计。

我的问题是，当不使用设计，但按照Railscast的东西是什么潜在的陷阱?他们的安全问题是我需要考虑的，在剧组中还没有涉及到吗?你还能想到其他陷阱吗?

编辑:为什么我不考虑使用设计?我不喜欢使用设计的部分原因是我不喜欢它的失败登录保护功能。按照设计的方式，任何人只要知道别人的电子邮件地址，就可以锁定别人的账户。在我看来，总的来说，我最好自己动手，而不是从内到外去了解设计来做这些改变，特别是如果我在未来的某个时候也需要用自己的方式做其他事情(这似乎很有可能)。

Answer 1

对于基本身份验证(这意味着只有一个用户名和密码)，推出您自己的身份验证不会有任何严重的缺陷。

现在，如果你还想:

• 记住登录用户的cookie
• 通过发送带有重置说明的电子邮件来恢复忘记的密码
• 报名需要邮件确认
• 超时用户会话在一段时间内没有活动

现在这些将是相当难以实现的。

因此，如果您只想要一个基本的身份验证系统，您可以愉快地使用自己的系统。但如果你担心你的应用的未来，那么也许你应该选择设计。这并不难理解，它提供了大量的功能，以后当你真正决定使用设计时，你将不必迁移你的数据。

编辑:所以，重申我说过的话。如果这是一个宠物项目，你只是想有一个基本的身份验证系统和授权系统，在那里你只允许某些用户查看某些页面，那么你可以自由地实现你自己的，并随着你的发展学习。

然而，如果这是更严重的事情，那么我不认为你有任何理由不使用设计。这让我想起了人们创建自己的哈希和加密方案，而他们可以(而且应该!)使用像bcrypt这样强大而安全的东西。

Answer 2

我之前也问过同样的问题。如果您希望真正深入研究并花一些时间在身份验证上，请创建自己的身份验证。但如果你想快速获得一些非常标准的东西，这样你就可以专注于应用程序的功能，我建议你使用design .

看起来Lockable模块在默认情况下甚至没有打开，但这两种方式都很容易做到。

class User < ActiveRecord::Base
    # Include default devise modules. Others available are:
    # :token_authenticatable, :confirmable,
    # :lockable, :timeoutable and :omniauthable
    devise :database_authenticatable, :registerable,
           :recoverable, :rememberable, :trackable, :validatable
    ...
end

另外，如果您确实使用了Lockable模块，由于锁定是基于失败的身份验证尝试次数，因此您可以在 config/initializers/devise.rb

中更改触发锁定之前的最大尝试次数。

Devise.setup do |config|
    ...
    # Number of authentication tries before locking an account if lock_strategy
    # is failed attempts.
    config.maximum_attempts = 20
    ...
end

快速浏览一下https://github.com/plataformatec/devise#devise