Как отлаживать React Web App, размещенный на WebServer и защищенный фильтром сервлетов

Question

Я работаю над приложением с ReactJS веб-интерфейсом и Java бэкэндом. Процесс сборки включает перенос JSX в пакетный файл. js, который затем копируется в бэкэнд-проект, который, в свою очередь, упаковывается как WAR и развертывается на Tomcat Server.

Обычный рабочий процесс включает javax.servlet.Filter, который перехватывает все http-запросы к серверу для проверки подлинности пользователя. Если нет, он перенаправляет на сервер OAuth для аутентификации. Ответ аутентификации затем сохраняется в сеансе http и используется фильтром для пропуска следующего запроса.

Таким образом, к моменту выполнения кода Javascript мне не о чем беспокоиться пользователь вошел в систему или нет. Я просто вызываю конечную точку отдыха /api/getCurrentUser, чтобы получить информацию о пользователе с того же сервера, на котором находится пакет. js. В работе все отлично работает!

Моя проблема в том, что я хочу отлаживать, изменять и тестировать код ReactJS без повторного развертывания всего приложения. Развертывание занимает около 3 минут, и этот процесс слишком болезненный для каждой изменяемой строки кода.

До применения фильтра авторизации я использовал Dev Server Webpack для размещения, отладки и горячая перезагрузка кода реакции. Все /api запросы были перенаправлены на экземпляр сервера, работающий на моей локальной машине. Теперь это невозможно, потому что когда я выполняю вызов API, на бэкэнде нет аутентифицированного пользователя, и фильтр перенаправляет вызов на сервер OAuth. Все потеряно отсюда.

Я знаю, что это Франкенштейн архитектуры, и это не то, что вы обычно видите, но у меня нет идей, как я мог заставить мою среду отладки работать снова. Мне нужно как-то аутентифицировать пользователя на бэкенде и использовать этот сеанс для отправки запросов API от Dev Server. У кого-нибудь есть идеи?

Answer 1

Интересно. Таким образом, создается впечатление, что ваш веб-сервер реализует поток OAuth и выдает auth cook ie - это правильно?

Затем также создаются данные сеанса и повторное развертывание веб-содержимого. c Содержимое сбрасывает приложение и стирает сеанс?

Или проблема заключается в том, что вам нужно использовать развернутый URI перенаправления? Не могли бы вы просто настроить 2 значения на сервере авторизации и использовать второй вариант при локальной разработке?

• Развернутый URL: https://myserver/myapp
• Локальный URL: http://localhost: 3000 / myapp

ПРЕДПОЧТИТЕЛЬНАЯ АРХИТЕКТУРА

Я часто вижу трудности, которых можно избежать, когда люди используют веб-приложения на стороне сервера - что является устаревшая концепция и вызывает больше проблем, чем решает. См. Мои Цели SPA . Пишите.

Возможно ли обеспечить безопасность клиента SPA? Может быть значительное преимущество в производительности и удобстве использования, и ваши заинтересованные стороны могут быть заинтересованы.

Я бы хотел поставить 2 таких компонента - ваша настройка React будет тогда абсолютно стандартной и продуктивной:

• Java Веб-API (защищенный с помощью маркеров доступа OAuth 2.0)
• React SPA (использует код авторизации + PKCE)

Из интереса мой Java Пример API + React SPA имеет именно эту настройку, или вы можете запустить мое онлайн-демонстрационное приложение React .

Дайте мне знать, если я неправильно понимаю - рад обсудить последующие действия вопросы.

Answer 2

Так что я нашел решение сам. Я собираюсь опубликовать здесь на случай, если кто-то еще сталкивается с этой проблемой.

@ gary-archer намекнул правильно:

Или проблема в том, что вы должны использовать развернутый URI перенаправления?

Мне нужно использовать URI перенаправления (он же /callback), развернутый на сервере OAuth. Этот URI изначально указывал на Backend Server (как видно на исходной диаграмме). Поэтому мне пришлось указать на мой экземпляр Web-сервера Dev, который, в свою очередь, перенаправил бы запрос /callback на внутренний сервер. Таким образом, данные сеанса HTTP должным образом инициализируются бэкендом, а Dev-сервер Webpack получает JSESSIONID Cook ie в ответе.

Для запуска моей среды у меня есть доступ http://webpack-url:webpack-port/login, который также пересылается на бэкэнд-сервер. Это в свою очередь перенаправляет на сервер OAuth для входа в систему. Я мог бы напрямую вызвать логин OAuth-сервера с внешнего интерфейса, но это означало бы переосмысление логики c, которая была на бэкэнде.