Как будут реализованы аутентификация и авторизация с использованием RavenDb в приложении MVC?

Хотя я привык использовать стандартного поставщика членства ASP.Net для новых веб-приложений MVC, в последнее время я получаю удовольствие от использования RavenDb, но я все еще не верю, что у меня есть представление о наилучшей практике реализации аутентификация пользователей и авторизация ролей.

Код, которым я заменил методы Register и Logon в AccountController, выглядит следующим образом:

[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, а для аутентификации с помощью форм), и правильно ли я лаю?


authentication asp.net-mvc authorization ravendb
person Phil.Wheeler    schedule 30.06.2012    source источник
comment
Я сделал (бета) поставщика для RavenDb здесь: github.com/jgauffin/griffin.mvccontrib/tree/master/source/ Он также доступен в виде пакета nuget: griffin.mvccontrib.ravendb Использование: github.com/jgauffin/griffin.mvccontrib/wiki/Membershipprovider   -  person jgauffin    schedule 30.06.2012
comment
Спасибо. Я видел несколько подходов к этой проблеме, и у Ayende также есть пакеты (например, расширения, грубо говоря), которые обращаются к auth. Я разместил свои выводы здесь: mytechworld.officeacuity.com/index.php/2012/07/   -  person Phil.Wheeler    schedule 12.07.2012

Ответы (1)


arrow_upward
2
arrow_downward

Я думаю, что есть несколько частей этой проблемы. Во-первых, с точки зрения проекта MVC вы действительно хотите использовать что-то, что будет работать с AuthorizationAttribute. На самом деле это не требует использования MembershipProvider как такового, а скорее вставляет соответствующий IPrincipal в HttpContext.Current.User, поскольку это то, на что эти атрибуты смотрят для авторизации.

С точки зрения HTTP, использование существующей инфраструктуры проверки подлинности с помощью форм также имеет большой смысл — она решает большинство неприятных проблем безопасности, которые вам действительно не следует решать самостоятельно, и она очень гибкая с точки зрения работы с тем, что вы предоставляете.

Оттуда вы переходите к сути вопроса — как вы хотите поддержать свою систему аутентификации с точки зрения данных. Я думаю, что это очень тактический подход — в некоторых приложениях может иметь смысл просто использовать модель стиля MembershipProvider. Но если бы у меня было приложение, очень ориентированное на пользователя, в котором я хранил бы много пользовательских данных, я бы, вероятно, подумал о развертывании пользовательского хранилища пользователей в соответствии с моими требованиями. Если вы используете пакет аутентификации, вы также можете в некоторой степени использовать его. Но я не думаю, что на данный момент существует жесткое правило — делайте то, что имеет смысл для вашего приложения.

Одна вещь, которую вы не должны делать, - это использовать AuthenticationUser, как указано выше, - это предназначено для пользователей системы баз данных. В терминах SQL Server это было бы похоже на то, чтобы сделать каждого пользователя в вашем приложении пользователем SQL, а затем выполнить аутентификацию против него. Именно так раньше работали некоторые старые интранет-продукты, но сейчас мир ушел от этого.

person Wyatt Barnett    schedule 30.06.2012