Действительно ли возможно создать Систему Входа в систему с ASP.NET MVC, но не использовать MembershipProvider?

Вы захотите, чтобы Ваши результаты были четко определены и повторяемы. К к этому, необходимо будет работать против известных данных так, чтобы можно было ясно определить и нормальные случаи и граничные случаи. В моей работе это всегда определенный сервер и набор данных, таким образом, модулю Поблочного тестирования встроили строку подключения. Другие предпочитают использовать строку подключения из проекта Поблочного тестирования. Я никогда не видел, что любой рекомендует использование файла конфигурации веб-сайта! (разработка или иначе)

58
задан LiamGu 17 September 2009 в 13:52
поделиться

4 ответа

У меня было точно такое же требование. У меня была собственная схема пользователей и ролей, и я не хотел переходить на схему членства asp.net, но я хотел использовать фильтры действий ASP.NET MVC для проверки авторизации и ролей. Мне пришлось изрядно покопаться, чтобы выяснить, что именно нужно сделать, но в конце концов это оказалось относительно легко. Я избавлю вас от хлопот и расскажу, что я сделал.

1) Я создал класс, производный от System.Web.Security.MembershipProvider. В MembershipProvider есть множество абстрактных методов для всех видов функций, связанных с аутентификацией, таких как забытый пароль, изменение пароля, создание нового пользователя и т. Д. Все, что мне нужно, это возможность аутентификации по моей собственной схеме. Итак, мой класс содержал в основном пустые переопределения. Я просто переопределил ValidateUser:

public override bool ValidateUser(string username, string password)
{
    if (string.IsNullOrWhiteSpace(username) ||
        string.IsNullOrWhiteSpace(password))
      return false;

    string hash = EncryptPassword(password);
    User user = _repository.GetByUserName(username);
    if (user == null) return false;

    return user.Password == hash;
}

2) Я создал класс, производный от System.Web.Security.RoleProvider. Опять же, у меня просто были пустые реализации для всей ненужной мне ерунды, такой как создание и изменение ролей. Я просто переопределил два метода:

public override string[] GetRolesForUser(string username)
{
    User user = _repository.GetByUserName(username);
    string[] roles = new string[user.Role.Rights.Count + 1];
    roles[0] = user.Role.Description;
    int idx = 0;
    foreach (Right right in user.Role.Rights)
        roles[++idx] = right.Description;
    return roles;
}

public override bool IsUserInRole(string username, string roleName)
{
    User user = _repository.GetByUserName(username);
    if(user!=null)
        return user.IsInRole(roleName);
    else
        return false;
}

3) Затем я подключил эти два класса в свой web.config:

<membership defaultProvider="FirstlookMemberProvider" userIsOnlineTimeWindow="15">
  <providers>
    <clear/>
    <add name="FirstlookMemberProvider" type="FirstlookAdmin.DomainEntities.FirstlookMemberProvider, FirstlookAdmin" />
  </providers>
</membership>
<roleManager defaultProvider="FirstlookRoleProvider" enabled="true" cacheRolesInCookie="true">
  <providers>
    <clear/>
    <add name="FirstlookRoleProvider" type="FirstlookAdmin.DomainEntities.FirstlookRoleProvider, FirstlookAdmin" />
  </providers>
</roleManager>

Вот и все. Фильтры действий авторизации по умолчанию будут использовать эти классы. Вам все равно придется обрабатывать страницу входа в систему и выходить из нее. Просто используйте для этого стандартные классы проверки подлинности с помощью форм, как обычно.

Вам все равно придется обрабатывать страницу входа в систему и выходить из нее. Просто используйте для этого стандартные классы проверки подлинности с помощью форм, как обычно.

Вам все равно придется обрабатывать страницу входа в систему и выходить из нее. Просто используйте для этого стандартные классы проверки подлинности с помощью форм, как обычно.

81
ответ дан 24 November 2019 в 18:56
поделиться

Когда кто-нибудь говорит вам, что что-то, связанное с безопасностью, «легко», они почти всегда ошибаются. В обеспечении безопасности есть множество тонкостей, которые неспециалисты, как правило, упускают.

В частности, любая форма аутентификации, которая явно не связана с кэшированием, по своей сути нарушена. Когда результат действия кэшируется, это происходит в ASP.NET, не обязательно в стеке ASP.NET MVC. Если вы изучите исходный код для AuthorizeAttribute, вы увидите, что он содержит немного сложный, но эффективный код, обеспечивающий его постоянное выполнение, даже если результат действия кэширован.

На сегодняшний день лучший способ настроить ASP. Проверка подлинности .NET MVC предназначена для написания настраиваемого поставщика членства в ASP.NET. Я не буду утверждать, что это надежно, но есть меньше способов получить проблемы с нарушенной реализацией безопасности на этом пути, чем с другими методами. Существенным преимуществом этого метода является то, что вы можете заменить другую систему авторизации практически в любое время без изменения кода.

Если вы должны реализовать собственный атрибут MVC, вам следует подтипировать AuthorizeAttribute и переопределить AuthorizeCore, внимательно следя за комментарии в исходном коде относительно безопасности потоков.

11
ответ дан 24 November 2019 в 18:56
поделиться

Конечно, можете. Я сделал это для своих проектов, полностью игнорируя поставщика членства.

Вам необходимо реализовать свой собственный ActionFilter. По сути, он перехватывает управление до того, как будет выполнено действие контроллера. В нем вы решаете, продолжить ли действие или перенаправить пользователя на страницу входа.

Для атрибута вы можете определить любые параметры, необходимые для поддержки вашей модели аутентификации / авторизации.

public class AuthorizationAttribute : ActionFilterAttribute, IActionFilter
{
   public MyRole UserRole { get; set; }

   void IActionFilter.OnActionExecuting (ActionExecutedContext filterContext)
   {
       // Decide whether to grant access to the action or redirect away
   }
}

[Authorization (UserRole = MyRole.All)]
public class UserController : Controller
{
    [Authorization (UserRole = MyRole.Admin)]
    public ActionResult Delete ()
    {
    }
}

Относительно проблем, выраженных в Комментарии. Да, включение кеша вывода помешает авторизации. Об этом просто нужно знать.

Объяснение проблемы: Совет №40 ASP.NET MVC - Не кэшируйте страницы, требующие авторизации

10
ответ дан 24 November 2019 в 18:56
поделиться

У вас есть как минимум две возможности

  • настраиваемый атрибут фильтра действий, который предоставит вам проверку авторизации
  • настраиваемый IHttpModule , который будет заполните все необходимые данные для вошедшего в систему пользователя (включая роли), и вы можете использовать существующие фильтры действий

Второй вариант можно использовать и с обычными веб-формами.

1
ответ дан 24 November 2019 в 18:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: