Comments 12
Интересный ньюанс, Спасибо.
Однако, судя по разделу «О себе» — Microsoft MVP & Microsoft Regional Director — статья должна заканчиваться примерно так:
«Также я создал bug в проекте MVC 5 — обещали исправить»
Однако, судя по разделу «О себе» — Microsoft MVP & Microsoft Regional Director — статья должна заканчиваться примерно так:
«Также я создал bug в проекте MVC 5 — обещали исправить»
Если таймаут истек, не всегда нужно перенаправлять пользователя на страницу ввода пароля после AJAX-запроса. Допустим, есть метод, который собирает статистику или строит график, отправляя аякс запрос через определенные промежутки времени и выводит результат в браузере. В таком случае для пользователя логичней было бы просто остановить отсылку запросов и оставить результат на экране, чем видеть логин-форму
context.Response.StatusCode == 0x191
HTTP коды в hex? ОК!
UFO just landed and posted this here
Спасибо. Тоже уже решал подобную проблему. Надо будет поковыряться в исходниках и сравнить.
Помню что принцип там такой же, но не помню на сколько учтены все нюансы.
Помню что принцип там такой же, но не помню на сколько учтены все нюансы.
Похожая проблема возникает при обработке серверных ошибок на стороне клиента. При выставлении Response.StatusCode = 503 происходит автоматический редирект на страницу ошибки. Для обхода этого механизма, стоит выставлять флаг Response.TrySkipIisCustomErrors = true; Как результат, например в базовом контроллере можно переопределить метод override void Execute(System.Web.Routing.RequestContext requestContext) и в try-cach:
if (Request.IsAjaxRequest()) {
Response.TrySkipIisCustomErrors = true;
Response.StatusCode = 500;
Response.StatusDescription = ex.Message.Trim(255);
Response.ContentType = "text/json";
Response.Write(new { errorMessage = ex.Message }.ToJson());
Response.SuppressContent = false;
Response.End();
}
На одном из проектов мы сделали следующее на клиентской стороне:
все ajax запросы мы проводили через общий метод, в котором при 401-ой ошибке запоминался success коллбек, показывался попап-логин и после удачной аутентификации запрос пересылался еще раз с выполнением всех коллбеков, пришедших ранее, т.е. по сути сценарий кода даже не замечал что авторизация упала. Очень удобно и практично получилось.
все ajax запросы мы проводили через общий метод, в котором при 401-ой ошибке запоминался success коллбек, показывался попап-логин и после удачной аутентификации запрос пересылался еще раз с выполнением всех коллбеков, пришедших ранее, т.е. по сути сценарий кода даже не замечал что авторизация упала. Очень удобно и практично получилось.
Sign up to leave a comment.
Корректная обработка проблем аутентификации AJAX-запросов для приложений ASP.NET MVC