Поддержка общего доступа к ресурсам независимо от источника (CORS) для службы хранилища Azure

Статья
07/11/2023

Начиная с версии 2013-08-15 службы хранилища Azure поддерживают общий доступ к ресурсам независимо от источника (CORS) для службы больших двоичных объектов, таблиц и очередей. Служба файлов поддерживает CORS, начиная с версии 2015-02-21.

CORS является функцией HTTP, которая позволяет веб-приложению, работающему в одном домене, обращаться к ресурсам из другого домена. Веб-браузеры реализуют ограничение безопасности под названием политика одного источника, которое не позволяет веб-странице вызывать интерфейсы API из другого домена; CORS обеспечивает безопасный способ, который разрешает одному домену (исходному домену) вызывать интерфейсы API в другом домене. Дополнительные сведения о CORS см. в спецификации CORS .

Правила CORS можно задать отдельно для каждой службы хранилища Azure, вызвав метод Set Blob Service Properties( Задать свойства службы BLOB-объектов), Set File Service Properties (Свойства службы файлов), Queue Service Properties (Свойства службы очередей) и Table Service Properties (Свойства службы таблиц). Как только будут заданы правила CORS для службы, прошедший авторизацию запрос к службе из другого домена будет оценен для определения его допустимости согласно заданным правилам.

Важно!

CORS не является механизмом авторизации. Любой запрос к ресурсу хранилища при включении CORS должен иметь допустимый заголовок авторизации или выполняться для общедоступного ресурса.

CORS поддерживается для всех типов учетных записей хранения, за исключением учетных записей хранения общего назначения версии 1 или 2 на уровне производительности "Премиум".

Общие сведения о запросах CORS

Запрос CORS из исходного домена может состоять из двух отдельных запросов:

Предварительный запрос, который запрашивает ограничения CORS, наложенные службой. Предварительный запрос является обязательным, если только методом запроса не является простой метод, например GET, HEAD или POST.
Фактический запрос нужного ресурса.

Предварительный запрос

Предварительный запрос запрашивает ограничения CORS, установленные для службы хранилища владельцем учетной записи. Браузер (или другой агент пользователя) отправляет запрос OPTIONS, содержащий заголовки запроса, метод и исходный домен. Служба хранилища оценивает планируемую операцию с учетом предварительно заданного набора правил CORS, которые указывают, какие исходные домены, методы и заголовки запросов могут быть указаны в фактических запросах к этому ресурсу хранилища.

Если для службы включен механизм CORS и установлены правила CORS, которым соответствует предварительный запрос, служба возвращает код состояния 200 (ОК) и включает в ответ требуемые заголовки Access-Control.

Если механизм CORS для службы выключен, либо предварительный запрос не соответствует ни одному правилу CORS, служба вернет код состояния 403 (доступ запрещен).

Если запрос OPTIONS не содержит необходимые заголовки CORS (заголовки Origin и Access-Control-Request-Method), служба вернет код состояния 400 (ошибочный запрос).

Обратите внимание, что предварительный запрос оценивается для службы (BLOB-объект, файл, очередь или таблица), а не для запрошенного ресурса. Владелец учетной записи должен включить CORS, задав соответствующие свойства службы учетных записей, чтобы запрос завершился успешно.

Фактический запрос

После принятия предварительного запроса и возврата ответа браузер отправляет фактический запрос к ресурсу хранилища. В случае отклонения предварительного запроса браузер немедленно запретит данный запрос.

Фактический запрос считается обычным запросом к службе хранилища. Наличие заголовка Origin показывает, что запрос является запросом CORS, и служба проверит его на соответствие правилам CORS. Если запрос соответствует правилам, в ответ будут добавлены заголовки Access-Control, после чего запрос будет отправлен обратно клиенту. Если соответствие не будет установлено, заголовки CORS Access-Control не возвращаются.

Включение CORS для службы хранилища Azure

Правила CORS задаются на уровне службы, поэтому необходимо включать или отключать CORS для каждой службы (BLOB-объектов, файлов, очередей и таблиц) отдельно. По умолчанию механизм CORS отключен для всех служб. Чтобы включить CORS, необходимо задать соответствующие свойства службы с помощью версии 2013-08-15 или более поздней для служб BLOB-объектов, очередей и таблиц либо версии 2015-02-21 или для службы файлов. Вы можете включить CORS, добавив правила CORS в свойства службы. Дополнительные сведения о включении или отключении CORS для службы и настройке правил CORS см. в разделе Установка свойств службы BLOB-объектов, Задание свойств файловой службы, Задание свойств службы таблиц и Задание свойств службы очередей.

Ниже приведен пример одного правила CORS, указанного Set Service Properties с помощью операции:

<Cors>
    <CorsRule>  
        <AllowedOrigins>http://*.contoso.com, http://www.fabrikam.com</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <AllowedHeaders>x-ms-meta-data*,x-ms-meta-target*,x-ms-meta-abc</AllowedHeaders>  
        <ExposedHeaders>x-ms-meta-*</ExposedHeaders>  
        <MaxAgeInSeconds>200</MaxAgeInSeconds>  
    </CorsRule>  
<Cors>

Ниже описаны все элементы, включаемые в правила CORS:

AllowedOrigins. Исходные домены, которым разрешено выполнять запросы к службе хранилища с помощью CORS. Исходный домен — это домен, из которого поступает запрос. Обратите внимание, что исходный домен должен в точности соответствовать исходному домену (с учетом регистра), из которого агент пользователя отправляет запрос к службе.

Вы можете использовать подстановочный знак "*" вместо указанного домена, чтобы разрешить всем доменам-источникам выполнять запросы через CORS. Вы также можете использовать подстановочный знак вместо поддомена, чтобы разрешить всем поддоменам данного домена выполнять запросы через CORS. В приведенном выше примере все поддомены contoso.com могут выполнять запросы через CORS, в то время как только запросы из www поддомена fabrikam.com разрешены через CORS.
AllowedMethods. Методы (команды HTTP-запросов), которые может использовать исходный домен для выполнения запроса CORS. В приведенном выше примере разрешены только запросы PUT и GET.
AllowedHeaders. Заголовки запросов, которые исходный домен может указывать в запросах CORS. В приведенном выше примере разрешены все заголовки метаданных, начиная с x-ms-meta-data, x-ms-meta-target и x-ms-meta-abc. Обратите внимание: подстановочный знак «*» указывает, что допустимыми являются все заголовки, начинающиеся с заданного префикса.
ExposedHeaders. Заголовки ответа, которые могут быть отправлены в ответ на запрос CORS и предоставлены отправителю запроса с помощью браузера. В приведенном выше примере браузеру дано указание предоставлять любые заголовки, начиная с x-ms-meta.
MaxAgeInSeconds. Максимальная продолжительность хранения предварительных запросов OPTIONS в кэше браузера.

Службы хранилища Azure поддерживают указание заголовков с префиксами и для элемента AllowedHeaders, и для элемента ExposedHeaders. Чтобы разрешить категорию заголовков, можно указать общий префикс для этой категории. Например, указав x-ms-meta* в качестве заголовка с префиксом, вы тем самым устанавливаете правило, которое соответствует всем заголовкам, начинающимся с x-ms-meta.

К правилам CORS применяются следующие ограничения:

Можно указать до пяти правил CORS для каждой службы хранилища (BLOB-объектов, файлов, таблиц и очередей).
Максимальный размер всех параметров правил CORS в запросе, за исключением XML-тегов, не должен превышать 2 КиБ.
Длина разрешенного заголовка, представленного заголовка или разрешенного исходного домена не должна превышать 256 знаков.
Разрешенные и представленные заголовки могут быть следующими:
- Литеральные заголовки с точным именем заголовка, например x-ms-meta-processed. В запросе может быть указано до 64 литеральных заголовков.
- Заголовки с префиксом, где указан префикс заголовка, например x-ms-meta-data*. Указанный таким образом префикс разрешает или предоставляет любой заголовок, который начинается с этого префикса. В запросе можно задать не более 2 заголовков с префиксами.
Методы (или HTTP-команды), указанные в элементе AllowedMethods , должны соответствовать методам, которые поддерживаются интерфейсами API службы хранилища Azure. Поддерживаемые методы: DELETE, GET, HEAD, MERGE, POST, PATCH, OPTIONS и PUT.

Общие сведения о логике оценки правил CORS

Если служба хранилища получает предварительный или фактический запрос, она оценивает этот запрос по правилам CORS, которые заданы для данной службы с помощью соответствующей операции Set Service Properties. Правила CORS оцениваются в порядке, в котором они были заданы в тексте запроса операции Set Service Properties.

Правила CORS оцениваются следующим образом:

Сначала исходный домен запроса проверяется по списку доменов, заданных в элементе AllowedOrigins. Если исходный домен есть в списке или все домены разрешены с помощью подстановочного знака «*», оценка правил будет продолжена. Если исходного домена нет в списке, выполнить запрос не удастся.
Затем метод (или HTTP-команда запроса проверяется по списку методов, заданных в элементе AllowedMethods. Если этот метод есть в списке, оценка правил будет продолжена. В противном случае выполнить запрос не удастся.
Если запрос соответствует правилу по своему исходному домену и методу, то это правило выбирается для обработки запроса, а проверка на соответствие другим правилам не производится. Однако запрос завершится успешно только после того, как все указанные в нем заголовки будут проверены по списку заголовков, заданных в элементе AllowedHeaders. Если переданные заголовки не будут соответствовать допустимым заголовкам, выполнить запрос не удастся.

Так как правила обрабатываются в порядке, в котором они заданы в тексте запроса, рекомендуется сначала указывать наиболее строгие правила, чтобы оценивать их в первую очередь. Менее строгие правила указывайте в конце списка, например правило, разрешающее все исходные домены.

Пример: проверка соответствия правилам CORS

В следующем примере показан частичный текст запроса операции задания правил CORS для служб хранилища. Дополнительные сведения о создании запроса см. в разделах Установка свойств службы BLOB-объектов, Задание свойств службы файлов, Задание свойств службы очередей и Задание свойств службы таблиц .

<Cors>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>PUT,HEAD</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>*</AllowedOrigins>  
        <AllowedMethods>PUT,GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-blob-content-type, x-ms-blob-content-disposition</AllowedHeaders>  
    </CorsRule>  
    <CorsRule>  
        <AllowedOrigins>http://www.contoso.com</AllowedOrigins>  
        <AllowedMethods>GET</AllowedMethods>  
        <MaxAgeInSeconds>5</MaxAgeInSeconds>  
        <ExposedHeaders>x-ms-*</ExposedHeaders>  
        <AllowedHeaders>x-ms-client-request-id</AllowedHeaders>  
    </CorsRule>  
</Cors>

Далее рассмотрим следующие запросы CORS:

Метод	Исходный домен	Заголовки запросов	Проверяемое правило	Результат
PUT	`http://www.contoso.com`	`x-ms-blob-content-type`	Первое правило	Успешное завершение
GET	`http://www.contoso.com`	`x-ms-blob-content-type`	Второе правило	Успешное завершение
GET	`http://www.contoso.com`	`x-ms-client-request-id`	Второе правило	Failure

Первый запрос соответствует первому правилу: исходный домен совпадает с допустимыми исходными доменами, метод соответствует допустимым методам, а заголовок — допустимым заголовкам, поэтому он будет успешно выполнен.

Второй запрос не соответствует первому правилу, так как используемый метод не соответствует допустимым методам. Тем не менее, он соответствует второму правилу, поэтому также будет успешно выполнен.

Третий запрос соответствует второму правилу по исходному домену и методу, поэтому соответствие другим правилам не проверяется. Однако заголовок x-ms-client-request-id не разрешен вторым правилом, поэтому запрос завершится ошибкой, несмотря на то что семантика третьего правила позволила бы ему завершиться успешно.

Примечание

Несмотря на то, что в этом примере менее строгое правило задано перед более строгим, в общем рекомендуется первыми задавать более строгие правила.

Общие сведения о задании заголовка Vary

Заголовок Vary является стандартным заголовком HTTP/1.1, который состоит из набора полей заголовка запроса, которые сообщают браузеру или агенту пользователя о критериях, выбранных сервером для обработки запроса. Заголовок Vary в основном используется для кэширования прокси-серверами, браузерами и CDN, и делается это для того, чтобы определить, как кэшировать ответ. Дополнительную информацию см. в спецификации заголовка Vary.

Если браузер или другой агент пользователя сохраняет ответ на запрос CORS в кэше, исходный домен кэшируется как разрешенный источник. Если второй домен выдает тот же запрос к ресурсу хранилища при активном кэше, агент пользователя получает кэшированный исходный домен. Второй домен не соответствует кэшированному домену, поэтому запрос все же не удастся выполнить, даже если по всем остальным параметрам он правильный. В некоторых случаях служба хранилища Azure задает для заголовка Vary значение Origin , чтобы агент пользователя отправлял последующий запрос CORS в службу, если запрашивающий домен отличается от кэшированного источника.

Служба хранилища Azure задает для заголовка Vary значение Origin для фактических запросов GET/HEAD в следующих случаях:

Если источник запроса точно соответствует разрешенному исходному домену, заданному правилом CORS. Чтобы соответствие было точным, правило CORS не может содержать символ-шаблон «*».
Источник запроса не соответствует ни одному правилу, но механизм CORS включен для службы хранилища.

Если запрос GET/HEAD соответствует правилу CORS, разрешающему все исходные домены, в ответе будет указано, что все они разрешены. А кэш агента пользователя также будет разрешать последующие запросы от любого исходного домена до тех пор, пока кэш будет активен.

Обратите внимание, что для запросов, в которых используются другие методы (отличные от GET/HEAD) службы хранилища не задают заголовок Vary, поскольку ответы на эти методы не кэшируются агентами пользователя.

В приведенной ниже таблице показано, как служба хранилища Azure будет реагировать на запросы GET/HEAD в описанных выше случаях.

Заголовок исходного домена есть в запросе	Правила CORS, заданные для этой службы	*Существует правило сопоставления, разрешающее все источники ()**	Существует соответствующее правило для точно совпадающего исходного домена	Ответ содержит заголовок Vary, которому присвоено значение Origin	*Ответ включает Access-Control-Allowed-Origin: ""**	Ответ содержит Access-Control-Exposed-Headers
Нет	Нет	Нет	Нет	Нет	Нет	Нет
Нет	Да	Нет	Нет	Да	Нет	Нет
Нет	Да	Да	Нет	Нет	Да	Да
Да	Нет	Нет	Нет	Нет	Нет	Нет
Да	Да	Нет	Да	Да	Нет	Да
Да	Да	Нет	Нет	Да	Нет	Нет
Да	Да	Да	Нет	Нет	Да	Да

Выставление счетов за запросы CORS

Счета за успешные предварительные запросы выставляются, если вы включили CORS для любой из служб хранилища для вашей учетной записи (путем вызова метода Set Blob Service Properties, Set Queue Service Properties, Set File Service Properties или Set Table Service Properties). Чтобы свести к минимуму затраты, элементу MaxAgeInSeconds в правилах CORS рекомендуется устанавливать большее значение с тем, чтобы агент пользователя сохранял запрос в кэше.

За невыполненные предварительные запросы плата не взимается.

См. также раздел

Спецификация общего доступа к ресурсам, независимо от источника W3C