Я думаю, здесь есть нечто большее, чем кажется на первый взгляд, и важно сначала понять CORS, а затем попытаться найти решения, когда люди приводят такие слова, как - Angular и т. Д. В обсуждении CORS.
Допустим, вы разработали и развернули API-интерфейсы с намерением использовать их из определенного кода пользовательского интерфейса, развернутого по адресу с определенным фиксированным URL / доменом . Как сервер, CORS - это способ сообщить клиентам (например, браузерам), что, хотя я и обслуживаю этот запрос, но я также говорю вам, что этот запрос пришел не из домена пользовательского интерфейса, который я, как сервер ожидал ( от по умолчанию - это должно быть того же происхождения ), чтобы вы предприняли необходимые действия. Когда браузер помечается сервером, он подавляет ответ сервера и показывает, что запрос не выполнен.
Выше приведено очень упрощенное описание, и вам следует больше узнать о политике Same Origin Security .
Кроме того, обратите внимание, что сервер помечает клиента, устанавливая заголовки ответа о происхождении, которое он поддерживает, но в любом случае обслуживает ответ, поэтому до этого момента вы должны понимать два момента,
- Он не имеет ничего общего с Angular и имеет все, что связано с браузером
- Это прерогатива клиента, что делать, если сервер сообщает ему, что запрос не пришел из источника / домена, от которого он ожидал. Обычно это делают только веб-браузеры, а не такие клиенты, как curl etc
С учетом всего вышесказанного, хотели бы вы, чтобы ваши API размещались в том же домене, что и домен UI? Если нет, то вам нужно изменить код на стороне сервера, чтобы явно указывать заголовки CORS, иначе браузер буду продолжать терпеть неудачу.
Решения,
1.Добавить аннотацию - org.springframework.web.bind.annotation.CrossOrigin к каждой из конечных точек.
2.Добавьте глобальную конфигурацию для каждого развертываемого модуля, как показано здесь . Преимущество заключается в том, что эти артефакты могут быть дополнительно развернуты в разных доменах.
Не просто копировать вслепую - вставьте эту строку, config.addAllowedOrigin("*");, установите для нее определенный домен, который вы хотите обслуживать, иначе нет смысла в такой безопасности.
3. Напишите еще один развертываемый артефакт, передающий ваши средства безопасности, такие как CORS и т. Д., И этот артефакт будет фронт для получения всех входящих запросов и последующего ответа после построения ответов из этих 30 конечных точек. Клиенты не будут напрямую взаимодействовать с этими 30 конечными точками, а только с этим артефактом. Очевидно, этот артефакт также будет необходим в той же области, что и эти 30 конечных точек.
Внесение изменений в 30 услуг не является жизнеспособным вариантом, кроме
внесение изменений в сторону услуг, есть ли другие варианты
доступны
Я не думаю, что есть какое-либо иное решение, кроме внесения изменений в код на стороне сервера. Никто за пределами вашей команды не может навязать это вам, потому что модель развертывания очень уместна и зависит от потребности по мере необходимости от организации к организации.
Источник * Заголовок отправляется в запросе и состоит из трех частей: протокола, хоста и номера порта.