是否值得搬到 SimpleMembership

Question

我有一个尚未发布的项目，但我不会很快发布，但几天前我将它从 mvc3 移到了 mvc4，在阅读时我看到了这个新的安全提供程序 SimpleMembership。
我现在实现安全的方式是使用MembershipProvider 和FormsAuthentication：

• 我已经实现了 ICustomPrincipal
• 我已经实现了 CustomPrincipalSerializeModel
• 我已经实现了 IPrincipal

注册用户我使用：

 MembershipCreateStatus status;
            Guid g = Guid.NewGuid();
            Membership.CreateUser(model.User.Email.Trim(), model.Password.Trim(), model.User.Email.Trim(), null, null, true, g, out status);

            if (status == MembershipCreateStatus.Success)
...
FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
                             1,
                             tUser.Email,
                             DateTime.Now,
                             DateTime.Now.AddDays(60),
                             true,
                             userData);

                    string encTicket = FormsAuthentication.Encrypt(authTicket);
                    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket);
                    Response.Cookies.Add(faCookie);
...

但正如我所见，SimpleMembership 看起来更干净，我想将项目移至它
但我对此有一些疑问：

1) 我对所有数据库操作都使用存储过程，我根本不使用 EF。如果我使用 SimpleMembership 是否可以在没有 EF 的情况下使用它？
2) 我是否需要为现实世界的应用程序构建自定义 SimpleMembership？
3) 我看到它为数据库创建表。我有我的表Users, Profiles, Roles and UsersInRoles 我可以将它应用到我的自定义架构吗？
4) 如果我想调用 WebSecurity.CreateAccount(...) 并且我想从负责调用创建用户的存储过程的域项目中调用一些我的自定义方法，我是否必须将其自定义并如果我必须这样做，是否有一些资源可以解释如何为用户和角色定制？

Answer 1

要了解 SimpleMembership 以及它是如何从以前的 Membership 实现演变而来并依赖于以前的 Membership 实现的，我建议阅读原始参考“Using SimpleMembership With ASP.NET WebPages (Matthew Osborn)”，以及我对“What is MVC4 security all about?”的更详细的回答，以更好地理解它。总结这些参考资料：

• 简单会员
  • 是一个涵盖SimpleMembershipProvider 和SimpleRoleProvider 的术语
  • 是与表单身份验证一起使用的存储和功能提供程序
  • 在 ASP.NET Forms 和 ASP.NET MVC 网站中工作，也可以在 ASP.NET Web API 和 SignalR 中使用，提供统一的身份验证和授权模型
• SimpleMembershipProvider
  • 通过 ExtendedMembershipProvider 抽象基类向原始 MembershipProvider 添加新功能，例如与开箱即用的 OAuth 提供程序集成
  • 创建 4 个您不/不应该与之交互的默认表（webpages_Membership、webpages_OAuthMembership、webpages_Roles、webpages_UsersInRoles）和一个（UserProfile），您可以按照自己的意愿构建
  • 与 WebSecurity 帮助类一起添加新功能
  • 从存储在原始 Membership 的单个 xml 字段中的“用户配置文件”移动到新的 UserProfile 表中更易于管理的每列属性（可使用 EF 完全自定义）

回答您的具体问题：

1) 我对所有数据库操作都使用存储过程，我根本不使用 EF。如果我使用 SimpleMembership，是否可以在没有 EF 的情况下使用它？

您通常不会直接与前缀为webpages_ 的表进行交互，因为Membership、WebSecurity 等中有API 级函数来执行您需要的所有业务功能。但是，没有什么可以阻止您通过存储过程与 UserProfile 进行交互，如果您不想利用 API，您甚至可以通过存储过程与 webpages_ 表进行交互（但您将只是复制 SimpleMembership 的所有好处（如果您这样做了）。

2) 我是否需要为实际应用构建自定义 SimpleMembership？

这在很大程度上取决于您想要做什么，但到目前为止，我还没有为任何现实世界的应用程序这样做。我在现有 API 的基础上进行了构建并添加了这些 API，但没有替换它们。

3) 我看到它为数据库创建表提供种子。我有我的表用户、配置文件、角色和 UsersInRoles 我可以将它应用到我的自定义架构吗？

如果您要迁移到 SimpleMembership，则必须将其中的数据移植到表 webpages_Membership、webpages_OAuthMembership、webpages_Roles、webpages_UsersInRoles 和 UserProfile。但是请注意，UserProfile 可以任意命名，您不必将其命名为 UserProfile。

4) 如果我想调用 WebSecurity.CreateAccount(...) 并且我想从负责调用创建用户的存储过程的域项目中调用一些我的自定义方法，我是否必须将其自定义，如果我必须这样做是否有一些资源可以解释如何为用户和角色定制？

有点难以理解您的要求，但是 WebSecurity.CreateAccount 执行以下操作：

• 在webpages_Membership 和
中创建记录
• 如果您使用WebSecurity.CreateUserAndAccount，则可以选择将属性添加到UserProfile

如果您想在您的数据库中执行其他操作，则需要在调用 WebSecurity.CreateAccount 之后调用它。您可以使用TransactionScope

将其设为事务性

但是，如果您想在一次调用 WebSecurity.CreateAccount 时将这一切包装起来，并使其调用您自己的域方法和存储过程，您将必须通过从 SimpleMembershipProvider（或 ExtendedMembershipProvider 继承）来创建自己的提供程序）。当WebSecurity.CreateAccount 然后调用ExtendedMembershipProvider.CreateAccount 时，它将遵循您的自定义逻辑

---

总结

那么我会迁移吗？ SimpleMembership 的好处是：

• UserProfile：用户数据的每列属性存储，可与 EF 或任何其他数据库开发方法配合使用
• 与 OAuth 集成，让您轻松使用 Google、Facebook 等身份验证
• WebSecurity 形式的高级业务功能 API，并通过 Membership 继续支持现有功能
• 继续支持使用 Authorize 属性的角色
• 与 EF 集成，以便您可以将 UserProfile 与您自己的表一起使用
• 与 ASP.NET 表单和 MVC 的标准表单身份验证集成，还与 SignalR 和 Web API 集成。

如果这些对您有帮助，请迁移，否则将您的开发时间花在应用程序的新功能上。

如果你决定迁移，那么“Migrating Legacy Apps to the New SimpleMembership Provider (Paul Brown)"”很有用，总结如下：

• 修改 UserProfile 为存储在 xml 中的旧用户配置文件属性的每个属性设置一个字段
• 将您的数据从 aspnet_ 表迁移到 webpages_ 表
• 每个用户第一次再次登录时，更新他们存储的密码以使用新的哈希模型而不是旧的 Membership （有关如何执行此操作，请参阅 the footnote to my answer here）

Answer 2

@Andy Brown 提出了很多好的观点。我会向任何对此进行说明的人指出，Simplemembership 基本上已经死了，并且随着 ASP.Net Identity 的出现而短暂存在，并且在所有新项目中都使用了它。如此短暂的会员产品。