[Authorize]
атрибут является хорошим и удобным изобретением MS, и я надеюсь, что это может решить проблемы, которые я имею теперь
Быть более конкретным:
Когда текущий клиент не аутентифицируется - [Authorize]
перенаправления от защищенного действия до страницы регистрации и после входа в систему были успешны - возвращает пользователя, это хорошо.
Но то, когда текущий клиент уже прошел проверку подлинности, но не разрешенный выполнить определенное действие - все, в чем я нуждаюсь, должно просто отобразить мои общие 403 страницы.
Действительно ли это возможно без движущейся логики авторизации в корпусе контроллера?
Обновление: поведение, в котором я нуждаюсь, должно быть, семантически равняется этому эскизу:
public ActionResult DoWork()
{
if (!NotAuthorized())
{
// this should be not redirect, but forwarding
return RedirectToAction("403");
}
return View();
}
таким образом - там должен, никакое любое перенаправление и URL не должны быть, остаются такими же, но содержание страницы должно быть заменено 403 страницами
Обновление 2: Я реализовал эскиз таким образом:
[HandleError]
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData["Message"] = "Welcome to ASP.NET MVC!";
return View();
}
[CustomActionFilter]
public ActionResult About()
{
return View();
}
public ActionResult Error_403()
{
return Content("403");
}
}
public class CustomActionFilter : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
filterContext.Result = new ContentResult { Content = "403" };
}
}
И не может добраться, как правильно передать выполнение HomeController. Action_403 (), таким образом, это отображается 403.
Обновление 3:
filterContext.Result = new ViewResult() { ViewName = "Error_403" };
таким образом, это - ответ о том, как представить определенный шаблон представления..., но все еще понятия не иметь, как выполнить другой контроллер - так или иначе, это - достаточно хорошего решения.
У вас должна быть возможность создать свой собственный класс, производный от AuthorizeAttribute
, и переопределить метод AuthorizeCore
, чтобы предоставить нужный механизм авторизации, чтобы вы могли применить пользовательскую авторизацию. код, используя атрибут вместо его перемещения в контроллер.
Если вам нужен более детальный контроль над авторизацией, я рекомендую вам создать реализацию интерфейса IActionFilter
(для атрибута, а затем применить атрибут к вашим методам). Это позволит вам перехватывать вызовы до того, как они перейдут к контроллеру, и предоставить альтернативные действия до вызова вашего метода контроллера.
Это достигается за счет реализации метода OnActionExecuting
в интерфейсе IActionFilter
. Если ваша логика определяет, что вам вообще не следует вызывать контроллер, и вы хотите предоставить вместо обработки ActionResult
, то вы должны установить свойство Result
] в экземпляре ActionExecutingContext
, переданном в метод. Таким образом, этот ActionResult
обрабатывается вместо перехода к методу контроллера для получения ActionResult
.
Если вы хотите вернуть код ошибки 403, вы не можете использовать класс ContentResult
.Вам нужно будет создать свой собственный класс, производный от ActionResult
, и переопределить метод ExecuteResult
, чтобы установить свойство StatusCode
в HttpResponseBase
до 403, например:
internal class Http403Result : ActionResult
{
public override void ExecuteResult(ControllerContext context)
{
// Set the response code to 403.
context.HttpContext.Response.StatusCode = 403;
}
}
public class CustomActionFilter : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
filterContext.Result = new Http403Result();
}
}
Конечно, вы можете обобщить класс Http403Result
, чтобы он принял конструктор, который будет принимать код состояния, который вы хотите вернуть, но концепция остается той же.