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

Ответ 1

У меня было это одно и то же требование. У меня была своя собственная схема пользователя и роли, и я не хотел мигрировать в схему членства 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>

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

Ответ 2

Всякий раз, когда кто-то говорит вам, что что-то связанное с безопасностью "легко", они почти всегда ошибаются. В безопасности есть много тонкостей, которые, как правило, не хватает.

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

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

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

Ответ 3

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

Вам нужно реализовать свой собственный 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 ()
    {
    }
}

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

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

Ответ 4

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

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

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