В настоящее время я работаю над проектом, который использует Zuul для прокси-запросов как к конечным точкам API, так и к ресурсам клиента. Существует угловое приложение, которое обслуживается с той же конечной точки, что и прокси Zuul, как описано в этом руководстве . У меня есть потребность в дополнительных клиентах, в частности, в настольном приложении.
Я не уверен, что понимаю, как прокси-сервер Zuul обрабатывает запросы, и я думаю, что есть несколько путей, чтобы добраться туда, куда я хочу пойти, я просто не уверен, какой правильный.
Вот что я догадался до сих пор:
Вариант 1. Извлечение возможностей прокси-сервера Zuul и SSO на свой собственный сервер. Затем создайте новый сервер пользовательского интерфейса, который находится за сервером шлюза. Затем создайте новый сервер клиентских приложений, который будет обрабатывать аутентификацию клиента рабочего стола.
Вариант 2. Извлечение возможностей прокси-сервера Zuul и SSO на свой собственный сервер. Обслуживайте текущее угловое приложение со своего собственного сервера НЕ за прокси и измените поток авторизации на что-то другое (неявное). Измените конфигурацию прокси-сервера Zuul и SSO, чтобы игнорировать запросы, в заголовке которых уже есть токен-носитель.
Если я перейду к варианту 2, то не пойму, как зарегистрироваться в клиенте шлюза Zuul, чтобы я уже предоставлял заголовок авторизации для своих запросов, поэтому все, что он должен делать, - это перенаправлять мои запросы на нужные микросервисы.
Заключительные вопросы:
- Какой вариант является наиболее оптимальным?
- Если токен доступа уже получен (напрямую с сервера аутентификации, использующего неявный поток), то как нужно настроить Zuul, чтобы он не пытался получить токен доступа с помощью jsessionid?