Была ли эта страница полезной?
Ваш отзыв об этом контенте важен для нас. Расскажите нам о том, что вы думаете.
Дополнительный отзыв?
1500 символов осталось
Экспорт (0) Печать
Развернуть все

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

Обновлено: Апрель 2015 г.

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

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

noteПримечание
Обратите внимание, что CORS не является механизмом проверки подлинности. Любой запрос к ресурсу хранилища, в котором включен механизм 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 (неправильный запрос).

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

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

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

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

Далее приведен образец одного правила CORS, заданного с помощью операции Set Service Properties.

<Cors>           <CorsRule>             <AllowedOrigins>http://www.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. В примере выше домены http://www.contoso.com и http://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.

  • Максимальный размер всех параметров правил CORS в запросе, за исключением XML-тегов, не должен превышать 2 КБ.

  • Длина разрешенного заголовка, представленного заголовка или разрешенного источника не должна превышать 256 символов.

  • Разрешенные и представленные заголовки могут быть следующими.

    • Литеральные заголовки с точным именем заголовка, например x-ms-meta-processed. В запросе может быть указано не более 64 литеральных заголовков.

    • Заголовки с префиксом, где указан префикс заголовка, например x-ms-meta-data*. Указанный таким образом префикс разрешает или предоставляет любой заголовок, который начинается с этого префикса. В запросе можно указать не более 2 заголовков с префиксами.

  • Методы (или HTTP-команды), указанные в элементе AllowedMethods, должны соответствовать методам, поддерживаемым интерфейсами API службы хранилища Azure. Поддерживаемые методы: DELETE, GET, HEAD, MERGE, POST, OPTIONS и PUT.

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

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

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

  2. Затем метод (или HTTP-команда запроса проверяется по списку методов, заданных в элементе AllowedMethods. Если этот метод есть в списке, то оценка правил продолжится. Если же его там нет, запрос завершится ошибкой.

  3. Если запрос соответствует правилу по своему домену-источнику и методу, то это правило выбирается для обработки запроса, а проверка на соответствие другим правилам не производится. Однако запрос завершится успешно только после того, как все указанные в нем заголовки будут проверены по списку заголовков, заданных в элементе AllowedHeaders. Если переданные заголовки не соответствуют допустимым заголовкам, то запрос завершится ошибкой.

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

В следующем примере показан частичный текст запроса для операции задания правил 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:

 

Request

Response

Method

Origin

Request headers

Rule Match

Result

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

Второе правило

Ошибка

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

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

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

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

Заголовок 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 для любых служб хранилища из своей учетной записи (вызвав Задание свойств службы BLOB-объектов, Задание свойств службы очередей или Задание свойств службы таблиц). Чтобы свести к минимуму затраты, элементу MaxAgeInSeconds в правилах CORS рекомендуется устанавливать большее значение с тем, чтобы агент пользователя сохранял запрос в кэше.

Неудачные предварительные запросы в счет не включаются.

См. также

Показ:
© 2015 Microsoft