我一直在查看有关电子邮件激活的示例，大多数示例只有一个激活令牌列，并在其用户表中确认。我不确定，但我认为这不是一个好主意，因为当用户被激活时，几乎这两个列似乎都是浪费。我正在考虑进行激活的方式是使用一个名为Activation的单独模型，它将have_one :user一个单向关联，我会将用户在我的网站中的角色设置为“PENDING”或类似的东西。激活表将为每个用户保存一个激活令牌。然后，将使用激活令牌生成链接，并向用户发送包含www.mysite.com/activate?token='some_really_long_hash'之类的内容的电子邮件。单击链接后，我的用户角色将设置为“MEMBER”或类似的东西。这看起来是个好主意吗？我无法想象这种激活的任何陷阱。建议？评论
答案 0 :(得分：2)
听起来你正处于在用户模型上实现状态机设计模式的介绍阶段，并不是一个糟糕的设计方法。它比大多数人需要的更复杂。
我认为State Machine Plugin可能是您希望执行的方法类型。显然，这可能比你正在寻找的更多，但方法将是相同的。
另请查看这些帖子：
祝你好运！
答案 1 :(得分：1)
最直接的方法是生成随机令牌并将其保存到用户或成员记录的列中。它不一定是“非常长”，20个随机字符就足够了，因为猜测的概率很小，永远不会发生。
通常，令牌仅使用一次以验证用户，但如果用户随后点击电子邮件，那么如果它仍然重定向回他们的个人资料则很好。
通常用户切换到“已验证”或类似的东西，状态标志存储在单独的列中。这会保留其初始成员资格类型，这可能是众多价值观之一。这就是您经常看到validated_at字段或banned_until字段的原因。