ASP.NET身份和ASP.NET成员资格提供程序"Mashup"

Question

我们有一个现有的Web应用程序,它是基于MVC和SQL成员资格提供程序构建的,用于用户身份验证.该应用程序还包括管理员管理屏幕,用于创建/编辑用户,重置密码,激活帐户等...这是一个相当成熟的系统,已经生产了大约2.5年.

我们现在有了通过API从系统中公开一些数据的新要求,我们将WebApi视为候选技术.

我遇到的一个问题是身份验证.我想利用我们应用程序中现有的用户/角色管理功能来创建和管理API帐户.但是,由于WebAPI的首选选项是使用ASP.NET身份(声明/承载令牌等...),我对最佳选择将会有些困惑.

在现有的会员提供商用户/密码认证中以某种方式将角斗机用于web api auth mechs是可能的还是坏的.有一种方法ApplicationOAuthProvider,看起来我可以通过IdentityUser user = await userManager.FindAsync(context.UserName, context.Password);调用MembershipProvider 替换该行来操作.尽管如此,这似乎非常有说服力.

思想和选项将不胜感激.

Answer 1

并不是真正的答案，只是我的 0.02 美分。

我认为您将花费与正确更新到新的 Idenitty 框架所需的时间一样多的时间来将 MembershipProvider 硬塞到新的 Identity 中。

我已经在 2 个不同的系统中完成了升级，两个系统都不小（一个 200K，另一个 70K 行代码），用户数量也有所增加。较小的系统花了我 7 个工作日，较大的系统花了 5 天（我第二次知道我在做什么 -）。两个系统都扩展了用户管理代码的数量，其中一个系统可以为管理员模拟另一个用户。一切都很顺利，没有出现停机情况。用户没有注意到差异。
但升级后，用户管理/身份验证变得更加容易，您很快就会花 5 天的时间进行升级。将此视为一项投资 -))

我查看了 MembershipProvider 的源代码（在反编译器中），很多东西都是静态的、混乱的、密封的并且根本无法管理。我想说，转储它会更容易，而不是构建更多遗留代码，只是为了维护垂死的库。

换句话说，更新所有内容会比尝试重新使用旧的东西更容易。