← Cloudflare R2 / r2 / buckets

Настройка CORS

Cross-Origin Resource Sharing (CORS) ↗ является стандартизированным методом, который запрещает домену X доступ к ресурсам домена Y. Для этого используются специальные заголовки в HTTP-ответах домена Y, благодаря которым браузер может убедиться, что домен Y разрешает домену X доступ к этим ресурсам.

CORS помогает защитить ваши данные от вредоносных сайтов, но при этом также используется для взаимодействия с объектами в бакете и настройки политик бакета.

CORS используется при взаимодействии с бакетом из веб-браузера. У вас есть два варианта:

Откройте бакет для публичного доступа: Этот вариант делает ваш бакет доступным в интернете в режиме только для чтения, то есть любой человек может запрашивать и загружать объекты из вашего бакета в браузере или где угодно ещё. Этот вариант отлично подходит, если ваш бакет содержит изображения, используемые в публичном блоге.

Presigned URL: Позволяет любому, у кого есть доступ к уникальному URL, выполнять определённые действия с вашим бакетом.

Прежде чем настраивать CORS, у вас должно быть:

• Бакет R2, содержащий хотя бы один объект. Если вам нужно создать бакет, см. Создание публичного бакета.
• Домен, который можно использовать для доступа к объекту. Это также может быть localhost.
• (Необязательно) Ключи доступа. Ключ доступа необходим только при создании presigned URL.

Чтобы использовать CORS с публичным бакетом, убедитесь, что бакет настроен на разрешение публичного доступа.

Затем, добавить CORS-политику к вашему бакету, чтобы разрешить общий доступ к файлу.

Presigned URLs предоставляют временный доступ для выполнения определённых действий с вашим бакетом без раскрытия ваших учётных данных. Presigned URL берут на себя аутентификацию, но вам всё равно нужно настроить CORS при отправке запросов из браузера.

Когда браузер отправляет запрос к presigned URL с другого источника, он применяет политику CORS. Без настроенной политики CORS загрузка и скачивание файлов через браузер с использованием presigned URL завершатся ошибкой, даже если сам presigned URL действителен.

Истекшие подписанные URL-адреса возвращают 403 ExpiredRequest ответ. R2 не включает заголовки ответа CORS в ответы с истекшими предварительно подписанными URL-адресами, поэтому JavaScript браузера не может прочитать тело ошибки. Обновляйте предварительно подписанные URL-адреса до их истечения или направляйте запросы через сервер вашего приложения, если браузеру нужно обрабатывать ошибки истечения срока действия напрямую.

Чтобы включить доступ из браузера с помощью presigned URL:

1. Добавление CORS-политики к вашему бакету, разрешающее запросы с источника вашего приложения.

2. Задайте AllowedMethods чтобы соответствовать операциям, которые выполняют ваши presigned URL, используйте GET, PUT, HEAD, и/или DELETE.

3. Задайте AllowedHeaders чтобы включить любые заголовки, которые клиент будет отправлять при использовании presigned URL, например заголовки для типа содержимого, контрольных сумм, кеширования или пользовательских метаданных.

4. (Необязательно) Задайте ExposeHeaders чтобы разрешить вашему JavaScript читать заголовки ответа, такие как ETag, который содержит хеш объекта и полезен для проверки загрузок.

5. (Необязательно) Задайте MaxAgeSeconds чтобы кешировать ответ на preflight запрос и уменьшить число preflight запросов, которые делает браузер.

Следующий пример разрешает загрузку из браузера с https://example.com с Content-Type заголовок:

[
  {
    "AllowedOrigins": ["https://example.com"],
    "AllowedMethods": ["PUT"],
    "AllowedHeaders": ["Content-Type"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3600
  }
]

Пользовательские домены подключённые к бакету R2 с настроенной политикой CORS, автоматически возвращают заголовки ответа CORS для кросс-доменные запросы ↗.

Межсайтовые запросы должны содержать корректный Origin заголовок запроса, например, Origin: https://example.com. Если вы тестируете напрямую или используете инструмент командной строки, например curl, вы не увидите CORS Access-Control-* заголовки ответа, если Origin заголовок запроса включен в запрос.

1. На панели управления Cloudflare перейдите к разделу Объектное хранилище R2 страницу.

   Перейдите в Обзор ↗

2. Найдите свой бакет в списке и выберите его.

3. Выберите Настройки.

4. В разделе Политика CORS, выберите Добавление CORS-политики.

5. Из раздела JSON вкладке вручную введите или скопируйте и вставьте свою политику в текстовое поле.

6. Когда закончите, выберите Save.

Ваша политика отображается на Настройки страница для вашего бакета.

Вы можете настроить правила CORS с помощью Wrangler CLI.

1. Создайте JSON-файл с конфигурацией CORS:

{
  "rules": [
    {
      "allowed": {
        "origins": ["https://example.com"],
        "methods": ["GET"]
      }
    }
  ]
}

2. Примените CORS-политику к своему бакету:

npx wrangler r2 bucket cors set <BUCKET_NAME> --file cors.json

3. Убедитесь, что политика CORS применена:

npx wrangler r2 bucket cors list <BUCKET_NAME>

Перечисленные ниже поля политики CORS R2 соответствуют заголовкам ответа HTTP. Эти заголовки ответа возвращаются только в том случае, если входящий HTTP-запрос является допустимым CORS-запросом.

В этом примере показана политика CORS, добавленная для бакета, который содержит Roboto-Light.ttf объект, представляющий собой файл шрифта.

AllowedOrigins указывает используемый веб-сервер, и localhost:3000 это имя хоста, на котором запущен веб-сервер. AllowedMethods указывает, что только GET запросы разрешены и могут читать объекты в вашем бакете.

[
	{
		"AllowedOrigins": ["http://localhost:3000"],
		"AllowedMethods": ["GET"]
	}
]

В целом, чтобы убедиться, что правила CORS настроены верно, полезно изучить сетевой запрос, который блокируется браузером.

• Убедитесь, что AllowedOrigins включает источник, с которого выполняется запрос (например, http://localhost:3000 или https://yourdomain.com)
• Убедитесь, что AllowedMethods включает метод заблокированного запроса.
• Убедитесь, что AllowedHeaders включает заголовки заблокированного запроса.

Также учтите, что распространение правила CORS в редких случаях может занимать до 30 секунд.

• Заголовки ответа CORS включаются только в кросс-доменный запрос.
  • Кросс-доменный запрос определяется наличием Origin заголовок HTTP-запроса со значением Origin представляющее допустимый разрешенный источник, как определено в AllowedOrigins поле вашей CORS-политики.
  • Запрос без Origin заголовок HTTP-запроса будет не возвращать какие-либо заголовки ответа CORS. Значения Origin должны совпадать точно.
• Значение(-я) для AllowedOrigins в вашей политике CORS должно быть допустимым Значение заголовка HTTP Origin ↗. Действительный Origin заголовок выполняет то же действие, что и не включать компонент пути и должны состоять только из scheme://host[:port] (где порт указывается по желанию).
  • Действителен AllowedOrigins значение: https://static.example.com : включает схему и хост. Порт указывается по желанию и по умолчанию определяется схемой.
  • Недопустимый AllowedOrigins значение: https://static.example.com/ или https://static.example.com/fonts/Calibri.woff2 : неверно включает компонент пути.
• Если вам нужно получать доступ к значениям определённых заголовков через JavaScript на исходной странице, например при использовании видеоплеера, обязательно настройте Access-Control-Expose-Headers корректно и включать заголовки, доступ к которым нужен вашему JavaScript, например Content-Length.