Как изящно обрабатывать логическое завершение для вызова Ajax?

Мое веб-приложение составлено из множества вызовов Ajax на стороне сервера RESTful APIs. Каждый раз, когда клиент регистрируется на моем сайте, страница входа в систему получает маркер JWT (JSON Web Token) с сервера и сохраняет его как cookie на стороне клиента. (Я предпочитаю хранить его как cookie, потому что это единственный способ позволить браузеру отправлять его автоматически, и он считается более безопасным, чем веб-хранилище HTML5). Там поле в токене, описывающее дату истечения маркера. Для каждого вызова Ajax токен отправляется для аутентификации.

Если клиент остается на моей странице долгое время, токен может истечь. И сервер обнаружит это, когда клиент сделает следующий HTTP-запрос (а не только вызов REST). Я использую servlet filter для перехвата запросов all HTTP и проверки маркера для истечения срока действия. Если токен истек, будет отправлен ответ перенаправление на регистрацию.

Но есть проблема с вышеприведенным подходом: "Как изящно обрабатывать ответ перенаправление на логин-страницу на стороне клиента?"

Для non-Ajax инициированного HTTP-запроса я могу полагаться на браузер, чтобы обрабатывать ответ перенаправления на логин и автоматически переходить на страницу.
Для Ajax инициированного HTTP-запроса кажется, что мне нужно добавить дополнительную логику к each ajax-вызову completion handler, чтобы обнаружить ответ перенаправления на регистрацию и imperatively сделать переход страницы,

Или я полностью ошибаюсь?

Некоторые ссылки:

Автоматическое продление срока действия JWT (JSON Web Token)

Какую стратегию аутентификации следует использовать для моего API?

Неявная и явная аутентификация

ДОБАВИТЬ 1:

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

Из здесь:

Если ответ является перенаправлением HTTP (код статуса 301, 302, 303 или 307), то он ДОЛЖЕН быть прозрачно соблюден (если он не нарушает безопасности или бесконечных циклов). Любая другая ошибка (включая 401) ДОЛЖНЫ заставить объект использовать эту страницу ошибки в качестве ответа.

Поймать 302 НАЙДЕНО в JavaScript

Как управлять запросом перенаправления после вызова jQuery Ajax

Ответ 1

Именно по этой причине веб-API не должны отвечать 302 redirect, но с 401 unauthorized, когда токен истек.

Веб-приложения должны возвращать ответы 302, поскольку они всегда предназначены для использования браузерами, такими как агенты. Для получения дополнительной информации см. Также мой ответ здесь.

Ответ 2

Да, я думаю, что ты прав.

Для не-ajax вы можете обработать его в конце сервиса с помощью перенаправления.

Для ajax вы можете переключать страницу в зависимости от результата ajax.

Ответ 3

Переадресация 302 не будет работать для вызова javascript (ajax), она просто вызовет новую страницу из javascript, а не фактический браузер.

Оптимальное решение - вернуть объект json с сообщением об ошибке и отобразить это сообщение об ошибке. или затем с помощью javascript, чтобы изменить местоположение на странице входа в систему

Ответ 4

Вы можете использовать Глобальный обработчик событий Ajax для работы в целом.

Попробуйте поймать .ajaxError(), а затем проверьте, не истекает ли его срок действия сеанса или что-то еще и ведут себя соответственно.

Я не пытаюсь это быть честным, но это стоит того.