Аутентификация и авторизация в ASP.NET MVC 5
Asp.net MVC 5, похоже, оставил работу с использованием класса AuthorizeAttribute, где вы можете создать собственный атрибут авторизации, выполнив класс AuthorizeAttribute, переопределив его методы и сокрыв свойство SiteRole, которое вы хотите испечь в своих собственных ролях. Все примеры, которые я видел, либо предлагают использовать OWIN, либо систему идентификации. Это только два способа сделать аутентификацию и авторизацию в новой структуре ASP.Net?. Я пропущу что-нибудь, если я сделаю это старомодным способом? Я не хочу, чтобы инфраструктура создала для меня все пользовательские и ролевые таблицы. Что делать, если я хочу добавить существующую таблицу пользователей и ролей в новое приложение?
Я также пока не вижу необходимости в социальной интеграции в каждом приложении, и не думаю, что мне это понадобится сразу же. Существует ли какая-либо статья, объясняющая начало с минимальным минимальным использованием пользовательского атрибута авторизации, а затем добавление новых функций проверки подлинности. Я хочу что-то, что в основном объясняет все беспорядки во вновь создаваемом проекте с отсутствием аутентификации или индивидуальной аутентификации пользователя.
Ответы
Ответ 1
Вы все равно можете настроить атрибут AuthorizeAttribute в MVC 5, используя идентификатор ASP.NET. Пример этого в SimpleSecurity Project. Вот настраиваемый авторизованный атрибут, который вы можете использовать для контроллеров, и здесь настроено AuthorizeAttribute you может использоваться для веб-API. Концепция этих настраиваемых атрибутов AuthorizeAttributes заключается в отделить вашу модель безопасности от вашей модели приложения, которая обсуждается здесь. Для веб-API также поддерживается базовая аутентификация.
Конвейер безопасности изменился с введением OWIN, и я столкнулся с некоторыми проблемами с поведением AuthorizeAttribute для веб-API, который обсуждался здесь.
Вы также найдете примеры в проекте SimpleSecurity при переносе старого поставщика членства под названием SimpleMembership в MVC 5. Некоторые из проблем с процессом обновления обсуждаются здесь. Я действительно заработал, чтобы вы могли пойти со старой реализацией поставщика членства. Но моя рекомендация состояла бы в том, чтобы пойти с идентификатором ASP.NET, так как это будет продолжаться, что Microsoft будет поддерживать, это более гибкая архитектура и устраняет многие из проблемы, обнаруженные в старых реализациях поставщика членства.
Ответ 2
Ben Foster имеет серию из двух частей, которая позволяет вам выполнить шаги по реализации аутентификации на основе файлов cookie с использованием ASP.NET Identity, начиная с нового веб-приложения без аутентификации. Следуйте за "Идентификацией ASP.NET без ограничений" Часть 1 и Часть 2.
используйте следующий атрибут Authorize для обработки несанкционированного доступа, когда пользователь уже прошел аутентификацию.
public class LoggedOrAuthorizedAttribute : AuthorizeAttribute
{
public LoggedOrAuthorizedAttribute()
{
View = "error";
Master = String.Empty;
}
public String View { get; set; }
public String Master { get; set; }
public override void OnAuthorization(AuthorizationContext filterContext)
{
base.OnAuthorization(filterContext);
CheckIfUserIsAuthenticated(filterContext);
}
private void CheckIfUserIsAuthenticated(AuthorizationContext filterContext)
{
// If Result is null, we’re OK: the user is authenticated and authorized.
if (filterContext.Result == null)
return;
// If here, you’re getting an HTTP 401 status code. In particular,
// filterContext.Result is of HttpUnauthorizedResult type. Check Ajax here.
if (filterContext.HttpContext.User.Identity.IsAuthenticated)
{
if (String.IsNullOrEmpty(View))
return;
var result = new ViewResult {ViewName = View, MasterName = Master};
filterContext.Result = result;
}
}
}