Запрос CloudFront CORS с использованием подписанных файлов cookie и withCredentials, без отправки обратно Access-Control-Allow-Credentials, если я не включу дополнительный заголовок

У меня очень странная проблема, которую я никак не могу решить. Я настроил частную раздачу CloudFront для обслуживания контента из частной корзины S3. Я использую подписанные файлы cookie для предоставления доступа к файлам. Я также делаю перекрестные запросы из браузера для файлов, поэтому мне нужно разрешить учетные данные для отправки файла cookie. Для этого я настроил пользовательскую политику заголовков ответов (я установил для Access-Control-Allow-Credentials значение true, явно установил Access-Control-Allow-Origin для моего предполагаемого домена и установил Access-Control-Allow-Methods/ Access-Control-Max-Age соответственно, и для него задано переопределение происхождения), и я также настроил пользовательскую политику кэширования для кэширования на основе заголовков происхождения и управления доступом.

эта команда cURL не дает правильного ответа:

curl -v -H "происхождение: https://my-subdomain.my-domain.com" -H "cookie: CloudFront-Key-Pair-Id=MyKeyPairID; CloudFront-Policy=Base64EncodedPolicy; CloudFront-Signature=SignedPolicy" https ://мой-другой-субдомен.мой-домен.com/key/to/my/private/file.txt

получается следующее:

< HTTP/1.1 200 ОК
< Content-Type: application/octet-stream
< Длина содержимого: 576
< Соединение: поддержание активности
< Дата: пятница, 18 февраля 2022 г., 18:34:09 по Гринвичу
< Последнее изменение: четверг, 16 декабря 2021 г., 14:45:12 по Гринвичу
<ETag: "a50884915242f9876bea4bb633963191"
< Accept-Ranges: байты
< Сервер: AmazonS3
< Варьируются: Происхождение, Заголовки-запроса-управления-доступом,Метод-запроса-управления-доступом
< Access-Control-Allow-Origin: https://my-subdomain.my-domain.com
< Варьировать: Происхождение
< X-Cache: удар из облака
< Через: 1.1 redacted.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: EWR50-C1
< X-Amz-Cf-Id: JxMbPWHeQr0a9AAlf9PI5ksF6xGKVWL1LvpEC9XEoR_PVuVgiJ5zGA==
<Возраст: 626

Обратите внимание на отсутствующий Доступ-Контроль-Разрешить-Учетные данные заголовок.

Однако эта команда дает правильный ответ:

curl -v -H "X-some-header: ерунда" -H "происхождение: https://my-subdomain.my-domain.com" -H "cookie: CloudFront-Key-Pair-Id=MyKeyPairID; CloudFront- Policy=Base64EncodedPolicy; CloudFront-Signature=SignedPolicy" https://my-other-subdomain.my-domain.com/key/to/my/private/file.txt

возвращает:

< HTTP/1.1 200 ОК
< Content-Type: application/octet-stream
< Длина содержимого: 576
< Соединение: поддержание активности
< Дата: пятница, 18 февраля 2022 г., 18:34:09 по Гринвичу
< Последнее изменение: четверг, 16 декабря 2021 г., 14:45:12 по Гринвичу
<ETag: "a50884915242f9876bea4bb633963191"
< Accept-Ranges: байты
< Сервер: AmazonS3
< Варьируются: Происхождение, Заголовки-запроса-управления-доступом,Метод-запроса-управления-доступом
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Origin: https://my-subdomain.my-domain.com
< Варьировать: Происхождение
< X-Cache: удар из облака
< Через: 1.1 redacted.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: EWR50-C1
< X-Amz-Cf-Id: pUSouCDwLH5Zu6-NBUZqKrb5kY407GLqXXtH4EK2-Th0Z9zZNb54ag==
<Возраст: 693 года

на этот раз с правильным Доступ-Контроль-Разрешить-Учетные данные заголовок. Я понятия не имею, что я мог неправильно настроить, чтобы вызвать это, или почему это могло произойти. Мы будем очень признательны за любые идеи, любые конфигурации или тестовые результаты, просто дайте мне знать.

Спасибо

РЕДАКТИРОВАТЬ:

После некоторых проб и ошибок я определил, что проблема связана с параметром переопределения источника в политике заголовков ответа. Когда для этого установлено значение true, он не будет отправлять заголовок Access-Control-Allow-Credentials, если вы не отправите какой-либо посторонний заголовок со своим запросом. Это проблема, поскольку она также вызывает нежелательные предварительные запросы в браузере.

Отключив этот параметр, а затем настроив CORS моего ведра S3, чтобы он выглядел так, как показано ниже, это было исправлено:

[
    {
        "Разрешенные заголовки": [
            "*"
        ],
        "Разрешенные методы": [
            "ПОЛУЧАТЬ",
            "ГЛАВНЫЙ"
        ],
        "Разрешено происхождение": [
            "https://*",
            "http://*"
        ],
        «Разоблачить заголовки»: [
            "ETag"
        ]
    }
]

Тем не менее, мне все еще любопытно, неправильно ли я понял настройку переопределения источника и есть ли способ сделать это правильно, или это какая-то ошибка в CloudFront.

РЕДАКТИРОВАТЬ 2:

Политика запроса источника: AWS Managed CORS-S3Oriign (я пробовал с этим и без политики, тот же результат)

Политика кэширования: пользовательская политика для кэширования на основе заголовков Origin и управления доступом, также пробовалась со стандартной управляемой политикой CacheOptimized и политикой NoCache, чтобы убедиться, что у меня нет проблем с застреванием запросов без учетных данных в кеше. Также попытался вручную аннулировать кеш и посмотреть, повлияли ли попадания или промахи, но это не так.

Политика заголовков ответа: пользовательская, чтобы разрешить учетные данные, это исходная конфигурация. В конце концов я установил для переопределения источника значение false, и все заработало, если я перенастроил свою политику S3 CORS для установки заголовков. У меня есть случайное значение под Access-Control-Allow-Headers потому что мне не разрешили оставить это поле пустым по какой-либо причине. Отправленный случайный заголовок не обязательно должен совпадать с заголовком, установленным здесь, чтобы вернуть заголовок учетных данных, но он должен совпадать для прохождения предварительной проверки браузера. Я также немного возился с настройкой заголовков expose, ничего не помогло.

Далее обратите внимание: как только S3 правильно настроил заголовки CORS, я смог полностью удалить политику заголовков ответа, но мне пришлось сохранить настраиваемую политику кэширования, иначе разные источники могли получить неправильные заголовки. Это также не идеально, так как у меня будут пользователи, обращающиеся к этим файлам из разных источников, и я полагаю, что если бы политика заголовков ответов работала правильно, она устанавливала бы заголовки после того, как они были извлечены из кеша, а не кэшировали заголовки (но я может ошибся в этом). Кажется, мой единственный другой вариант — это какая-то функция CF, работающая с ответами, но это влечет за собой дополнительные затраты и накладные расходы, в то время как функционирующая политика заголовков ответов была бы бесплатной и более эффективной.

Но что очень странно, так это то, что даже если S3 правильно устанавливает заголовки CORS, если я использую политику заголовков ответа с переопределением источника true, она все равно прерывает ответ без прикрепленного случайного заголовка.