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

Question

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

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

Но есть проблема, связанная с вышеприведенным подходом: «Как изящно обрабатывать ответ на адрес на стороне клиента?»

• Для non-Ajax возник запрос HTTP, я могу полагаться на браузер для обработки ответа Перенаправление-на-логин-страницу и страницу скачка автоматически.

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

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

Некоторые рефов:

JWT (JSON Web Token) automatic prolongation of expiration

Which authentication strategy should I use for my API?

Implicit & Explicit authentication

ADD 1:

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

От here:

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

Catching 302 FOUND in JavaScript

How to manage a redirect request after a jQuery Ajax call

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

Вы можете использовать Global Ajax Event Handler для полного завершения сеанса связи.

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

Я не пробовал это, если честно, но это стоит того.