【问题标题】:Asp.net Identity 2.0 temporary passwordAsp.net Identity 2.0 临时密码
【发布时间】:2014-10-22 16:56:24
【问题描述】:

在我的 MVC 应用程序中,用户注册以两种方式实现;用户注册并经管理员批准;或者管理员可以创建用户。我的问题是:是否可以发送一个临时密码,然后用户必须在首次登录后更改它,或者我可以将此用户标记为第一次使用外部身份验证。 非常感谢您的建议。

【问题讨论】:

    标签: c# asp.net asp.net-mvc asp.net-identity


    【解决方案1】:

    你可以像这样定义一个 UserAccount 类:

    public class UserAccount
    {
       public int AccountId {  get; set;}
    
       public UserAccountState AccountState { get; set; }
    
       public Guid ActivationCode { get; set; }
    
       public string Password { get; set; }
    }
    

    UserAccountState 在哪里

    public enum UserAccountState
    {
       PendingActivation = 0,
       UsingTempPassword = 1
       Normal = 2
    }
    

    当新用户刚刚注册时。您可以将他的帐户设置为PendingActivation 状态并向他发送激活帐户的链接,如下所示

    www.MySite.com/Activate?code=F3D17EE
    

    当用户点击链接时,您将用户帐户与代码匹配,并执行以下操作:

    1. 为帐户生成临时密码,例如“TempPass12”
    2. 将账户状态改为UsingTempPassword
    3. 向用户显示以下消息 "您的帐户现已激活。单击此处使用您的临时密码登录 TempPass12"

    用户使用临时密码登录您的站点后,您的代码应检测到UserAccountState 处于UsingTempPassword 状态,然后将用户重定向到更改密码页面。

    用户提供新密码后,账户可以进入Normal状态。

    【讨论】:

    • 仅仅重定向是不够的。如果您登录用户,他们将能够绕过更改密码表单。如果您不登录,他们将无法访问更改密码表单。
    【解决方案2】:

    在您的密码表中添加一列,例如“ForceToChangePassword”。每次用户登录时检查该列,如果设置为 true,则将用户重定向到更改密码页面。

    【讨论】:

      【解决方案3】:

      我的意见是使用角色而不是使用新列,并且每次用户登录时都检查一下,因为当我们考虑性能时这并不好。

      创建三个可能的新角色

      • 已创建 - 管理员创建的用户
      • 已注册 - 用户自行注册
      • 已批准 - 由管理员批准

      在您的情况下,如果用户自己注册,则将它们添加到 ROLE 'Registered'。如果用户由管理员创建,则将其添加到 ROLE 'Created'。一旦管理员批准或用户在第一次登录时更改密码,那么您可以将它们添加到 ROlE 'Approved'

      然后您可以处理用户自我注册和管理员创建控制器操作,以将用户添加到正确的角色。

      已经有一个名为'EmailConfirmed' 的列,因此您可以将该列用于您的目的。当用户在首次登录时批准或成功更改密码时更新该列。

      如您所知,密码字段可以为空,因此您不需要插入临时密码(但如果您愿意,也可以)。您可以将密码字段保留为空,并在用户首次登录时对其进行更新。您需要更改视图以支持这种情况。

      您可以使用 asp.net 身份框架支持的方法来实现这一点。

      GenerateEmailConfirmationTokenAsync
      GenerateEmailConfirmationToken
      IsEmailConfirmedAsync
      ConfirmEmailAsync
      

      此基于角色的方案可以帮助您根据角色对用户进行分类,并使用[Authorize(Role = "RoleName")] 轻松限制访问。

      如果您需要更多详细信息,请告诉我。

      希望这会有所帮助。

      【讨论】:

      • 登录是比较少见的情况。我不会认为任何额外的列对性能的影响都很大。无论如何,系统都会在您登录时为您获取ApplicationUser 对象。多一列不会有任何区别。并且试图为用户的状态重新定位角色是一个糟糕的表现。如果需要实际角色,例如“顾问”和“管理员”,将“已批准”混入其中会破坏 SRP。
      猜你喜欢
      • 2017-10-20
      • 2015-08-09
      • 1970-01-01
      • 1970-01-01
      • 2013-11-26
      • 2013-10-31
      • 2015-05-31
      • 1970-01-01
      相关资源
      最近更新 更多