авторизоваться и продолжить - REST

можно просто при каждом запросе обновлять сессию, чтобы эти 60 минут снова шли

Но это не спасёт от засады, если у меня открыто окно с ответом, я отвлёкся, вернулся на 59-й минуте, дописал и отправил.

я бы этого не пережил

да, я сам думаю, как это реализуют. может stevejobs знает, как это в спринге принято делать?

Интересный момент.

Касаемо вопроса, можно так реализовать по сути: можно просто открывать дополнительный слой формы авторизации.

Имхо афаик ссзб ббпе, пост отправляется сам после релогина, если там spring & tomcat.

На сервере можно сделать подобное. К примеру принимаешь POST /add-comment и видишь, что пользователь не аутентифицирован. Сохраняешь весь запрос, например, в /tmp/123 и отправляешь пользователю редирект на страницу аутентификации вида HTTP 302 Location: /login?return-post=123. Пользователь загружает эту страницу, при сабмите формы параметр return-post тоже посылается. После успешной аутентификации на сервере подменяется текущий запрос сохранённым и продолжается выполнение как с изначального момента. Если у тебя AJAX-запросы, тут даже проще - просто клиентский код должен повторить запрос после аутентификации, напиши какой-то общий транспортный код для обработки этой ситуации и всё.

Проще в мапу сложить. И надо наверно ещё о безопасности подумать. Если будут приниматься посты от кого угодно, то могут через этот временное хранилище завалить.

Ну да, хранить на сервере я думал, и про завалить тоже сразу подумал. Можно попробовать частично защититься так:

- ограничить число сессий N, которые может одновременно иметь каждый пользователь.

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

- при приёме протухшего запроса проверять, что его сессия - одна из этих N. Правда, если он напишет коммент, не отправит его, затем перейдёт на другое устройство, на нём N раз выйдет и зайдёт , а через два часа вернётся на первое устройство и попробует отправить коммент, то всё равно ему будет отказано и текст будет потерян.

Ну и другой вариант для AJAX - это просто сначала отправить запрос «обнови сессию». Если сессия протухла, то отправка сообщения с клиента не происходит, а вместо этого открывается форма логина (поверх существующей, это ж вроде можно). Если же сессия не протухла, то она продлевается на час и тогда мы смело отправляем уже основной запрос.

Можно и повторять, но это как-то менее красиво на вид.

Для чистого html такой способ не сработает, но ведь аскеты должны быть готовы к такой мелкой неприятности :)

Ну как то так и есть всё.

Если у тебя обычное для наших дней js приложение, я бы сделал как ты описал (я правда не понял, это ли ты имел ввиду, поэтому на всякий случай):

-- проверить на клиенте, не протухла ли сессия
-- если протухла, запускаем авторизацию (кажем окошко в первую очередь)
-- посылаем данные
-- если с сервера пришёл код «а у вас протухло», идём на пункт «если протухла»

т.е. по сути придётся дважды проверять «не протухло ли». в первый раз потому что так удобно, и если предполагать нормальную ситуацию, оно всегда или почти всегда будет срабавать там,экономяодин запрос. ну а второй раз топорный, от него вряд ли можно куда то деться.

вообще на вотрой раз (сервер ответил что вы неавторизованы) надо вешать обработчик где то в корне своих утилит для работы с сетью. и посылать евент кому надо.

Сейчас писал в приват на хабре и произошло вот что:

я написал сообщение, нажал отправить, форма перегрузилась, но мое сообщение не было отправлено, а так и было заполнено поле ввода. Я скопировал сообщение, обновил страницу, меня перебросило на форму авторизации. Я успешно залогинился, перебросило в ту форму диалога. Вставил из буфера сообщение и отправил.

Вот такой вариант развития событий мне кажется очень удобным, только нужна надпись «сохраните данные и перелогиньтесь». И осталось придумать, как это сделать на Spring+Security, который автоматом перебрасывает на форму авторизации и обратно при разлогине.

Spring это автоматом делает. Надпись notepad.exe :)

что это? редирект на тот урл, что был до переавторизации с сохранением всех параметров формы? а вот и нет.

Параметры формы — твоя работа. А переадресация авто.

это - да. но спринг автоматически переадресовывает на форму авторизации. а на хабре другое поведение: если не авторизован при POST запросе, то он возвращает на ту же форму, с которой был запрос, все поля заполнены.

не оно?

нет, это в рамках API. а мы с ТС говорили про серверную логику. фронт рендерится каким-нибудь Thymeleaf-ом

Не думаю, что то, что ты описал про хабр, делается серверной логикой. Она же stateless.

ну так я про нее и рассуждаю, но в рамках Спринга