虽然我已经习惯使用标准的ASP.Net会员提供程序来处理新的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成员资格提供者代码,但似乎也有很多人认为这个代码超过了顶层并利用效率低下的API数据存储不需要其中提供的大部分内容。
那么RavenDb身份验证的最佳架构/设计策略是什么(不是OAuth,而是表单身份验证),我是不是正确地吠叫了?
答案 0 :(得分:2)
我认为这个问题有几个部分。首先,从MVC项目的角度来看,您确实希望使用可与AuthorizationAttribute一起使用的东西。这实际上并不需要使用MembershipProvider本身,而是将适当的IPrincipal填充到HttpContext.Current.User中,因为这是这些属性用来授权的东西。
从HTTP的角度来看,利用现有的表单身份验证基础结构也很有意义 - 它解决了您自己真正不应该解决的大多数棘手的安全问题,并且在处理您的工作方面非常灵活提供。
从那里,您可以了解问题的要点 - 您希望如何从数据角度支持您的身份验证系统。我认为这是一个非常具有战术性的调用 - 一些应用程序可能只使用MembershipProvider样式模型。但是,如果我有一个非常以用户为中心的应用程序,我存储了大量用户数据,我可能会考虑根据我的要求滚动自定义用户存储。如果您正在使用身份验证包,那么您也可以在某种程度上看到它。但我认为目前还没有一条硬性规则 - 对您的应用程序做有意义的事情。
您不应该做的一件事是使用上面的AuthenticationUser--这适用于数据库系统用户。在SQL Server术语中,就像让您的应用程序中的每个用户成为SQL用户,然后对其进行身份验证。一些旧的内联网产品曾经如何运作,但现在世界已经过去了。