Пропуск заголовков access-control-allow в ответе CORS/preflight

У меня возникли проблемы с поиском информации, объясняющей, что произойдет, если ответ на предварительный запрос или ответ на фактический запрос CORS пропустит Access-Control-Allow-Headers. Я заметил, что некоторые сайты говорят, что этот заголовок необходим, когда запрос включает Access-Control-Request-Headers.

Я хотел бы разрешить доступ CORS к моему API с любыми заголовками, поэтому мне интересно, сделает ли пропуск этого заголовка именно это и разрешит все заголовки.

Мой API требует, чтобы вы отправили заголовок Authorization, содержащий токен OAuth, и обычно клиент также отправляет файл cookie. Есть сайты, которые говорят, что использование * вместо Access-Control-Allow-Headers действует как подстановочный знак только тогда, когда Access-Control-Allow-Credentials является false.

Кажется, это ставит меня в тупик, поскольку я хочу, чтобы запрос CORS включал учетные данные (заголовок Authorization и файл cookie), но я также хочу разрешить все заголовки. Как я могу заставить это работать?

Второстепенный вопрос: зачем мне ограничивать запрос разрешенным набором заголовков? В моем случае API — это GET, который не вносит изменений на сервер. Я хочу, чтобы разрешенные источники всегда могли получить эту информацию. При каких обстоятельствах заголовки, которые они включают, будут играть роль в этом?

Формы c голосовым вводом в React с помощью Speechly
Формы c голосовым вводом в React с помощью Speechly
Пытались ли вы когда-нибудь заполнить веб-форму в области электронной коммерции, которая требует много кликов и выбора? Вас попросят заполнить дату,...
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно...
Flatpickr: простой модуль календаря для вашего приложения на React
Flatpickr: простой модуль календаря для вашего приложения на React
Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей....
В чем разница между Promise и Observable?
В чем разница между Promise и Observable?
Разберитесь в этом вопросе, и вы значительно повысите уровень своей компетенции.
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
Четыре эффективных способа центрирования блочных элементов в CSS
Четыре эффективных способа центрирования блочных элементов в CSS
У каждого из нас бывали случаи, когда нам нужно отцентрировать блочный элемент, но мы не знаем, как это сделать. Даже если мы реализуем какой-то...
0
0
17
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

I’m having trouble finding information explaining what happens if the response to a preflight request or the response to the actual CORS request omits Access-Control-Allow-Headers. I have noticed that several sites say this header is required when the request includes Access-Control-Request-Headers.

Эти сайты верны: если предварительный запрос содержит заголовок Access-Control-Request-Headers, то ответ на этот запрос должен, по крайней мере, содержать заголовок Access-Control-Allow-Headers, иначе предварительная проверка CORS завершится ошибкой. Фактическое значение заголовка, необходимое для успешной предварительной проверки CORS, будет отличаться в зависимости от того, какие имена заголовков были указаны в запросе предварительной проверки.

I would like to allow CORS access to my API with any headers, so I’m wondering if omitting this header will do just that and allow all headers.

Нет, пропуск заголовка Access-Control-Allow-Headers в ответе на предварительный запрос не считается пропуском.

My API requires that you send an Authorization header containing an OAuth token and typically the client will also send a cookie. There are sites that say that using * for Access-Control-Allow-Headers only acts as a wildcard when Access-Control-Allow-Credentials is false.

Близко, но неточно. Скорее, вы не можете использовать подстановочный знак для Access-Control-Allow-Headers, если вы используете Access-Control-Allow-Credentials: true. См. https://fetch.spec.whatwg.org/#http-new-header-syntax

This seems to put me in a bind since I want the CORS request to include credentials (the Authorization header and a cookie) but I also want to allow all headers. How can I make this work?

В этом случае вы не можете использовать подстановочный знак. У вас есть только один способ: взять все имена заголовков, перечисленные в заголовке Access-Control-Request-Headers предварительного запроса, и отразить их в заголовке Access-Control-Allow-Headers ответа.

A secondary question is why would I want to restrict the request to an allowed set of headers? In my case the API is a GET which makes no changes on the server. I want allowed origins to always be able to retrieve this information. Under what circumstances would the headers they include play into that?

Я могу что-то упустить, но я не думаю, что это проблематично, если набор разрешенных источников конечен. Однако, если вы разрешаете произвольные источники, вам, вероятно, не следует разрешать произвольные заголовки на аутентифицированных конечных точках. В частности, разрешение Authorization для произвольного происхождения открывает дверь для клиентской стороны, распределенного перебора токенов Bearer (или того, что обычно содержит Authorization); подробнее об этом в https://github.com/whatwg/fetch/issues/251#issuecomment-209265586

Другие вопросы по теме