Это НЕ «еще один вопрос о поддержке CORS в Spring Security».
Я прекрасно понимаю, что существует элегантное решение - на самом деле более одного - использования CorsFilter, предоставляемого Spring, для того, чтобы предварительные запросы обходили цепочку фильтров аутентификации. Например, есть CorsConfigurationSource, а также есть CorsRegistry. Конечно, я предпочитаю эти решения, поскольку они интегрированы в Spring Security, в отличие от написания моего собственного фильтра и повторного предположения, правильно ли я рассматриваю все аспекты взаимодействия CORS.
Проблема в том, что CorsFilter делает именно то, что следует из названия, он обеспечивает специальную обработку запросов CORS перед полетом. Но если мы откроем спецификации метода HTTP 1.1, мы увидим, что, например, метод OPTIONS описывается без какой-либо ссылки на CORS! Таким образом, хотя он обычно используется браузерами, никто не говорит, что он не может быть использован каким-либо клиентом или кодом JavaScript, запущенным в браузере , но из того же домена (в этом случае я считаю, что браузер не будет заставлять заголовки CORS на исходящем запросе). Я даже нашел некоторые упоминания в Интернете о ВАРИАНТАХ, используемых для проверки «живучести» («ping» на сервере).
Я также знаю, что Spring будет успешно обслуживать запрос OPTIONS (не только кросс-источник, но любой), если будет разрешено.
Теперь у меня вопрос: каков рекомендуемый (предполагается?) Способ разрешить обходные проверки подлинности без междоменных опций?
P.S. Если вам интересно, как CorsFilter не может этого сделать: он проверяет наличие заголовков обязательных запросов CORS, таких как «Origin». Что не является обязательным, если это не междоменный запрос.