Атрибут ASP.NET MVC Authorize выполняет перенаправление 302, когда пользователь не авторизован - PullRequest
14 голосов
/ 20 октября 2010

MSDN явно говорит, что должно выполнить перенаправление 401, но я получаю перенаправление 302 на FF, и это вызывает проблемы в запросах AJAX, поскольку возвращаемое состояние равно 200 (со страницы перенаправления).

http://msdn.microsoft.com/en-us/library/system.web.mvc.authorizeattribute.aspx

Я нашел кого-то еще с той же проблемой: http://blog.nvise.com/?p=26

Любое другое решение, кроме его?

Ответы [ 4 ]

12 голосов
/ 15 июля 2011

Мне очень нравится это решение. Изменяя ответ 302 на запросы AJAX на 401, он позволяет вам настроить ваш AJAX на стороне клиента, чтобы отслеживать любой запрос AJAX, ищущий 401, и, если он находит, перенаправить на страницу входа. Очень просто и эффективно.

Global.asax:

protected void Application_EndRequest()
{
    if (Context.Response.StatusCode == 302 &&
        Context.Request.Headers["X-Requested-With"] == "XMLHttpRequest")
    {
        Context.Response.Clear();
        Context.Response.StatusCode = 401;
    }
}

Код на стороне клиента:

 $(function () {
      $.ajaxSetup({
        statusCode: {
          401: function () {
            location.href = '/Logon.aspx?ReturnUrl=' + location.pathname;
          }
        }
      });
    });
9 голосов
/ 21 октября 2010

Атрибут Authorize делает возвращает Http 401 Несанкционированный ответ. К сожалению, однако, если вы включили FormsAuthentication, 401 перехватывается модулем FormsAuthenticationModule, который затем выполняет перенаправление на страницу входа в систему, которая затем возвращает Http 200 (и страницу входа в систему) обратно на ваш запрос AJAX.

Лучшая альтернатива - написать свой собственный атрибут авторизации, а затем, если вы получите неаутентифицированный запрос, который также является Ajax-запросом, верните другой код состояния Http - скажем, 403 - который не перехватывается формойAmsAuthenticationModule, и вы можете перехватить в вашем методе Ajax.

5 голосов
/ 18 июля 2017

Я реализовал свой собственный атрибут авторизации, унаследованный от AuthorizeAttribute, и столкнулся с той же проблемой.

Затем я обнаружил, что начиная с .Net 4.5 существует решение этой проблемы - вы можете подавить перенаправление следующим образом:

context.HttpContext.Response.SuppressFormsAuthenticationRedirect = true;

Тогда ответом будет 401 - Несанкционированный, вместе с запросом проверки подлинности HTTP Basic.

Подробнее здесь

1 голос
/ 25 января 2018

Если вы используете веб-приложение ASP.NET MVC 5, перейдите на App_Start -> Startup.Auth.cs. Проверьте, включен ли app.UseCookieAuthentication, и посмотрите, установлено ли для CookieAuthenticationOptions значение LoginPath = new PathString("/Login"), или подобное. Если вы удалите этот параметр, 401 прекратит перенаправление.

Описание для LoginPath:

Свойство LoginPath сообщает промежуточному ПО, что оно должно изменить исходящий код 401 неавторизованного статуса в перенаправлении 302 на заданный путь входа в систему. Текущий URL, который сгенерировал 401, добавляется к LoginPath как параметр строки запроса, названный ReturnUrlParameter. Как только запрос к LoginPath предоставляет новый Идентификатор SignIn, значение ReturnUrlParameter используется для перенаправления браузер вернулся к URL, который вызвал исходный несанкционированный статус код. Если LoginPath пусто или пусто, промежуточное ПО не будет выглядеть для 401 несанкционированных кодов состояния, и он не будет перенаправлять автоматически при входе в систему.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...