Задание списков управления доступом для очередей

Операция Set Queue ACL задает хранимые политики доступа для очереди, которые могут использоваться с SAS (подписанным URL-адресом). Дополнительные сведения см. в разделе Определение хранимой политики доступа.

Примечание

Операция Set Queue ACL доступна в версии 2012-12-12 и последующей.

Запрос

Запрос можно создать Set Queue ACL следующим образом. Рекомендуется использовать ПРОТОКОЛ HTTPS. Замените myaccount именем своей учетной записи хранения:

Метод Универсальный код ресурса (URI) запроса параметр "Версия HTTP"
PUT https://myaccount.queue.core.windows.net/myqueue?comp=acl HTTP/1.1

Запрос службы эмулированного хранилища

При выполнении запроса к эмулированной службе хранилища укажите имя узла эмулятора и порт службы очередей в качестве 127.0.0.1:10001, за которым следует эмулированное имя учетной записи хранения:

Метод Универсальный код ресурса (URI) запроса параметр "Версия HTTP"
PUT http://127.0.0.1:10001/devstoreaccount1/myqueue?comp=acl HTTP/1.1

Дополнительные сведения см. в статье Использование эмулятора Azurite для разработки и тестирования службы хранилища Azure.

Параметры универсального кода ресурса (URI)

В запросе URI можно указать следующие дополнительные параметры.

Параметр Описание
timeout Необязательный элемент. Параметр timeout указывается в секундах. Дополнительные сведения см. в статье Установка времени ожидания для операций службы очередей.

Заголовки запросов

Обязательные и необязательные заголовки запросов описаны в следующей таблице:

Заголовок запроса Описание
Authorization Обязательный. Указывает схему авторизации, имя учетной записи и подпись. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure.
Date или x-ms-date Обязательный. Задает время запроса в формате UTC. Дополнительные сведения см. в статье Авторизация запросов к Службе хранилища Azure.
x-ms-version Необязательный элемент. Задает версию операции, используемой для этого запроса. Дополнительные сведения см. в разделе Управление версиями для служб хранилища Azure.
x-ms-client-request-id Необязательный элемент. Предоставляет созданное клиентом непрозрачное значение с ограничением в 1 кибибайт (КиБ), которое записывается в журналы при настройке ведения журнала. Мы настоятельно рекомендуем использовать этот заголовок для сопоставления действий на стороне клиента с запросами, получаемыми сервером. Дополнительные сведения см. в статье Мониторинг хранилища очередей Azure.

Текст запроса

Можно указать хранимую политику доступа, предоставив уникальный идентификатор и политику доступа в тексте запроса для операции Set Queue ACL.

Элемент SignedIdentifier включает уникальный идентификатор, как указано в элементе Id, и подробности политики доступа, как указано в элементе AccessPolicy. Максимальная длина уникального идентификатора составляет 64 знака.

Поля Start и Expiry должны быть выражены через время по Гринвичу (UTC) и соответствовать действительному формату ISO 8061. В число поддерживаемых форматов ISO 8061 входят следующие:

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.ffffffTZD

Для части даты таких форматов YYYY— представление года из четырех цифр, MM— представление месяца из двух цифр, а DD— представление дня из двух цифр. Для части hh времени — представление часов в 24-часовой нотации, mm двухзначное представление минуты, ss двухзначное представление секунды и ffffff шестизначное миллисекундное представление. Конструктор T времени отделяет части строки от даты и времени, а конструктор TZD часовых поясов задает часовой пояс.

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  
  

Пример запроса

Request Syntax:  
PUT https://myaccount.queue.core.windows.net/myqueue?comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2012-02-12  
x-ms-date: Sun, 25 Sep 2011 00:42:49 GMT  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2009-09-28T08:49:37.0000000Z</Start>  
      <Expiry>2009-09-29T08:49:37.0000000Z</Expiry>  
      <Permission>raup</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>  
  

Ответ

Ответ включает код состояния HTTP и набор заголовков ответа.

Код состояния

Успешная операция возвращает код состояния 204 (нет контента).

Дополнительные сведения о кодах состояния см. в разделе Коды состояния и ошибок.

Заголовки ответов

Ответ для этой операции включает следующие заголовки. Ответ может также включать дополнительные стандартные заголовки HTTP. Все стандартные заголовки соответствуют спецификации протокола HTTP/1.1.

Заголовок ответа Описание
x-ms-request-id Уникально идентифицирует выполненный запрос и может использоваться для устранения неполадок с запросом. Дополнительные сведения см. в статье Устранение неполадок с операциями API.
x-ms-version Указывает версию службы очередей, которая использовалась для выполнения запроса. Этот заголовок возвращается для запросов, выполненных в отношении версии 2009-09-19 и более поздних версий.
Date Значение даты и времени в формате UTC, созданное службой, которое указывает время инициации ответа.
x-ms-client-request-id Этот заголовок можно использовать для устранения неполадок запросов и соответствующих ответов. Значение этого заголовка равно значению заголовка x-ms-client-request-id , если он присутствует в запросе и содержит не более 1024 видимых символов ASCII. Если заголовок x-ms-client-request-id отсутствует в запросе, он не будет присутствовать в ответе.

Пример ответа

Response Status:  
HTTP/1.1 204 No Content  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: Sun, 25 Sep 2011 22:42:55 GMT  
x-ms-version: 2012-02-12  
Server: Windows-Azure-Queue/1.0 Microsoft-HTTPAPI/2.0  
  

Авторизация

Вызов этой операции доступен только владельцу учетной записи.

Комментарии

Только владелец учетной записи может получить доступ к ресурсам в определенной очереди, если только владелец не выдал подписанный url-адрес для ресурса в очереди.

При установке разрешений для очереди существующие разрешения заменяются. Чтобы обновить разрешения очереди, вызовите командлет Get Queue ACL для получения всех политик доступа, связанных с очередью. Измените политику доступа, которую вы хотите изменить, а затем вызовите Set Queue ACL с полным набором данных для выполнения обновления.

Установка хранимых политик доступа

Хранимая политика доступа может указать время начала, срок действия и разрешения для подписанных url-адресов, с которыми она связана. В зависимости от того, как вы хотите управлять доступом к ресурсу очереди, вы можете указать все эти параметры в хранимой политике доступа и опустить их в URL-адресе для подписанного URL-адреса. Таким образом вы можете в любое время изменить поведение связанной подписи или отозвать его. Вы также можете указать один или несколько параметров политики доступа в хранимой политике доступа, а другие — в URL-адресе. Наконец, можно указать все параметры в URL-адресе. В этом случае хранимую политику доступа можно использовать для отмены подписи, но не для изменения поведения подписи. Дополнительные сведения о создании политик доступа см. в статье Определение хранимой политики доступа.

Вместе подписанный URL-адрес и хранимая политика доступа должны включать все поля, необходимые для авторизации подписи. Если отсутствуют обязательные поля, запрос завершается ошибкой. Аналогичным образом, если поле указано как в URL-адресе подписанного URL-адреса, так и в хранимой политике доступа, запрос завершается ошибкой с кодом состояния 400 (недопустимый запрос).

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

При создании хранимой политики доступа в очереди может потребоваться до 30 секунд. В течение этого интервала подписанный URL-адрес, связанный с хранимой политикой доступа, завершается ошибкой с кодом состояния 403 (запрещено), пока политика доступа не станет активной.

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

Определение хранимой политики доступа
Получение списка управления доступом очереди
Авторизация запросов к службе хранилища Azure
Коды состояний и ошибок