6

虽然我已经习惯于将标准 ASP.Net Membership Provider 用于新的 MVC Web 应用程序，但我最近对使用 RavenDb 很感兴趣，但我仍然不相信我掌握了实现的最佳实践用户认证和角色授权。

我在 AccountController 中替换了我的 Register 和 Logon 方法的代码如下所示：

[HttpPost]
public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
    using (IDocumentSession Session = DataDocumentStore.Instance.OpenSession())
    {
        Session.Store(new AuthenticationUser
        {
            Name = Email,
            Id = String.Format("Raven/Users/{0}", Name),
            AllowedDatabases = new[] { "*" }
        }.SetPassword(Password));
        Session.SaveChanges();
        FormsAuthentication.SetAuthCookie(model.UserName, createPersistentCookie: false);
        // ...etc. etc.


    [HttpPost]
    public JsonResult JsonLogOn(LogOnModel model, string returnUrl)
    {
        if (ModelState.IsValid)
        {
            using (IDocumentSession Session = DataDocumentStore.Instance.OpenSession())
            {
                book Ok = Session.Load<AuthenticationUser>(String.Format("Raven/Users/{0}", Username)).ValidatePassword(Password);
                FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);
                // etc...

我已经看到许多人在类似的帖子或问题中引用的 RavenDb Membership Provider 代码，但似乎也有一些人认为这太过分了，并利用低效的 API 进行数据存储不需要其中提供的大部分内容。

那么 RavenDb 身份验证（不是 OAuth，而是表单身份验证）的最佳架构/设计策略是什么？

4

1 回答 1

2

我认为这个问题有几个部分。首先，从 MVC 项目的角度来看，您确实想要使用与 AuthorizationAttribute 一起使用的东西。这实际上不需要使用 MembershipProvider 本身，而是将适当的 IPrincipal 填充到 HttpContext.Current.User 中，因为这就是这些属性用来授权事物的方式。

从 HTTP 的角度来看，利用现有的表单身份验证基础设施也很有意义——它解决了您真正不应该自己解决的大多数棘手的安全问题，并且在处理您提供的内容方面非常灵活。

从那里您可以了解问题的要点——您希望如何从数据角度支持您的身份验证系统。我认为这是一个非常战术性的调用——某些应用程序可能只使用 MembershipProvider 样式模型是有意义的。但是，如果我有一个非常以用户为中心的应用程序，我在其中存储了大量用户数据，我可能会考虑根据我的要求推出自定义用户商店。如果您使用的是身份验证捆绑包，您也可以在某种程度上关注它。但我认为目前还没有硬性规定——做对你的应用有意义的事情。

您不应该做的一件事是像上面那样使用 AuthenticationUser ——这适用于数据库系统用户。在 SQL Server 术语中，这就像让您的应用程序中的每个用户都成为 SQL 用户，然后针对该用户进行身份验证。这就是一些旧的 Intranet 产品过去的工作方式，但现在世界已经过去了。

于 2012-06-30T16:42:05.530 回答