Как управлять авторизацией запроса с помощью токенов?
У меня есть своего рода проблема с разработкой, в основном мне нужно авторизовать пользователя для перехода / вызова определенной страницы / функциональности с помощью токена, эти страницы могут быть настроены так, чтобы требовать авторизацию по требованию (возможно, установка параметра в базе данных).
Приложение было создано с использованием Struts 1, поэтому я подумал о том, чтобы просто перехватить URL-адрес с помощью фильтра, проверить, требуется ли авторизация запроса, отправить токен по электронной почте и перенаправить пользователя на страницу "вставка токена", а затем снова перехватить через фильтр, если реферер был страницей токена, и проверить правильность значения, если это правильно, затем перенаправить на исходный запрос...
Однако я не могу просто восстановить предыдущий запрос, также фильтр перехватывает ServletRequest и Struts имеет более детальную конструкцию, поэтому я не могу потерять действие или объекты формы.
Я не уверен, что это хороший подход для решения этой проблемы, если да, мне нужно сохранить исходный запрос в памяти, и я не уверен, как это сделать.
Это устаревший проект, в котором много страниц и контроллеров, поэтому практически невозможно просто пройти каждый метод, выполняя проверки.
Я бы принял любое предложение, хорошего дня!:)
РЕДАКТИРОВАТЬ
Чтобы добавить больше контекста, в проекте есть много форм, созданных с помощью Struts, поэтому внутренне Struts отображает html-форму в POJO, чтобы получить их в качестве параметров в методах действий (контроллеров): ActionMapping и ActionForm. Когда я создаю фильтр, мои параметры - это объекты ServletRequest, ServletResponse и FilterChain, напрямую у меня нет ActionMapping или ActionForm, но я знаю, что они являются частью структуры запроса, так как я не знаю, как их получить напрямую, я пытаюсь работать со всем запросом, отсюда проблемы безопасности и размера, а также потому, что я не знаю, как сохранить копию исходного запроса, пока я делаю операцию перенаправления
3 ответа
После нескольких дней в поисках правильного решения я решил изменить идею, вместо того, чтобы переписать (очень небезопасным образом) запрос, я разработал двустороннее решение, с внешней стороны я перехватываю любой запрос с помощью JavaScript, я делаю Первоначальная проверка URL-адреса, а затем запросить токен, поэтому, наконец, я отправляю дополнительный параметр, который я могу получить в фильтре, а затем после выполнения проверки я могу продолжить исходный запрос или создать перенаправление. Спасибо всем за потраченное время и предложения, думаю, лучше объяснить, чем я занимался, вместо того, чтобы оставлять эту тему в эфире.
Учитывая объем информации, которую любит передавать Struts, у меня будет соблазн сохранить сеанс где-нибудь в безопасности для возвращения пользователя. В этом посте рассказывается о похожей идее, хотя вы могли бы просто сохранить сеансы под ключом токена.
Однако осознание того, что эта идея будет зависеть от среды, например, от того, как быстро пользователь вернется с токеном, и общего числа пользователей, для которого необходимо масштабировать.
Я бы рассмотрел зашифрованные файлы cookie HTTP (если политика конфиденциальности вашего приложения разрешает использование файлов cookie).
Вы можете сохранить необходимую информацию для последующего использования и истечь через некоторое время. Кроме того, вам не нужно беспокоиться о хранении и масштабировании сессии. Сдается мне, отвечает всем требованиям.
Сказав это, есть детали, которые вы должны рассмотреть. В частности, шифрование cookie.
Обновить
Примечание о больших объектах в cookie. Создание большого HTTP-заголовка не всегда хорошая идея. Большинство веб-серверов даже устанавливают максимальный размер заголовка (см. Максимальное значение заголовка http?). Вам необходимо сериализовать двоичные данные в кодировке Base64, что делает их еще больше.
Если ваши объекты действительно большие (например, конструкции Struts), которые не помещаются в заголовок HTTP. Вы, вероятно, не хотите хранить их в сеансе в памяти. Возможно, вы захотите рассмотреть сеанс с поддержкой базы данных, если это возможно.
Tomcat (если это ваш веб-контейнер) имеет один JDBCStore, и вы можете настроить его. Это не очень хорошо, хотя иметь запрос к базе данных на каждый запрос / ответ.
Альтернативой хранению всех сеансов в базе данных является сохранение только этого конкретного объекта в базе данных и сохранение его связанного ключа в файле cookie HTTP. Это то, что я, вероятно, сделал бы, учитывая размер объекта.
Это в основном компромисс между памятью и скоростью. (Я не знаю точных требований вашего приложения с точки зрения ресурсов и производительности).