У меня есть два проекта. Оба являются реактивными Spring. Первый проект представляет собой комбинацию приложения Javascript и Spring Cloud Gateway для обратного проксирования. Второй проект — сервер ресурсов Spring.
Первый проект передает запросы от /api/artists на второй проект в http://localhost:8081/v1/artists.
Если я вызываю сервер ресурсов (второй проект) напрямую с действительным JWT, ответ возвращается HTTP 200. Если я использую обратный прокси-сервер в первом проекте и нажимаю http://localhost:8080/api/artists с тем же JWT, я получаю HTTP 403 от проект два, который распространяется обратно через проект один.
Вот моя конфигурация Spring Cloud Gateway:
spring:
cloud:
gateway:
routes:
- id: experience-api
uri: http://localhost:8081/v1/artists
predicates:
- Path=/api/artists/**
filters:
- TokenRelay=
HTTP 403 указывает, что, хотя токен был действительным, у него должно отсутствовать какое-либо другое разрешение для выполнения действия. Хотя я не уверен, почему это работает, когда я вызываю его напрямую, а не через обратный прокси-сервер/Spring Cloud Gateway.
Отойдя на пару дней, я понял, что конфигурация моего шлюза неверна. Я понял, что исходная конфигурация проксировала запросы к /v1/artists/api/artists, которого нет во втором проекте, но моя конфигурация безопасности была настроена так, что /v1/** требовала аутентификацию. Я подозреваю, что именно поэтому я увидел HTTP 403 Forbidden до того, как увидел HTTP 404 Not Found.
В итоге я использовал следующую конфигурацию:
spring:
cloud:
gateway:
routes:
- id: experience-api
uri: http://localhost:8081
predicates:
- Path=/v1/artists/**
filters:
- TokenRelay=
Обратите внимание, что я удалил /v1/artists из свойства uri. Теперь запросы на проецирование одного из них в http://localhost:8080/v1/artists перенаправляются в http://localhost:8081/v1/artists. Я мог бы использовать фильтр предикатов StripToken, но он не был таким чистым, как этот.