VENDAS: 1-800-867-1389

Suporte a CORS (Compartilhamento de recursos entre origens) para os serviços de armazenamento do Azure

Atualizado: novembro de 2013

A partir da versão 2013-08-15, os serviços de armazenamento do Windows Azure dão suporte a Compartilhamento de Recursos entre Origens (CORS) para serviços Blob, Tabela e Fila. CORS é um recurso de HTTP que permite a execução de um aplicativo Web em um domínio para acessar recursos em outro domínio. Os navegadores da Web implementam uma restrição de segurança conhecida como política de mesma origem que evita que uma página da Web chame as APIs em um domínio diferente; o CORS fornece uma maneira segura de permitir que um domínio (o domínio de origem) chame APIs em outro domínio. Consulte a especificação de CORS para obter detalhes sobre o CORS.

Você pode definir as regras de CORS individualmente para cada um dos serviços de armazenamento, chamando Definir propriedades do serviço Blob, Definir propriedades do serviço Fila e Definir propriedades do serviço Tabela. Depois de definir as regras de CORS para o serviço, uma solicitação autenticada corretamente feita em relação ao serviço de um domínio diferente será avaliada para determinar se é permitida de acordo com as regras que você especificou.

noteObservação
Observe que CORS não é um mecanismo de autenticação. Qualquer solicitação feita em relação a um recurso de armazenamento quando o CORS estiver habilitado deverá ter uma assinatura de autenticação adequada ou deverá ser feita em um recurso público.

Uma solicitação de CORS de um domínio de origem pode consistir em duas solicitações separadas:

  • Uma solicitação de simulação, que consulta as limitações de CORS impostas pelo serviço. A solicitação de simulação será necessária a menos que o método da solicitação seja um método simples, significando GET, HEAD ou POST.

  • A solicitação real, feita no recurso desejado.

A solicitação de simulação consulta as restrições de CORS que foram estabelecidas para o serviço de armazenamento pelo proprietário da conta. O navegador da Web (ou outro agente do usuário) envia uma solicitação OPTIONS que inclui os cabeçalhos, o método e o domínio de origem da solicitação. O serviço de armazenamento avalia a operação pretendida com base em um conjunto pré-configurado de regras de CORS que especificam quais os domínios de origem, os métodos de solicitação e os cabeçalhos de solicitação podem ser especificados em uma solicitação real em um recurso de armazenamento.

Se CORS estiver habilitado para o serviço e houver uma regra CORS que corresponde à solicitação de simulação, o serviço responderá com o código de status 200 (OK) e incluirá os cabeçalhos Access-Control necessários na resposta.

Se CORS não estiver habilitado para o serviço ou nenhuma regra CORS corresponder à solicitação de simulação, o serviço responderá com o código de status 403 (proibido).

Se a solicitação OPTIONS não contiver os cabeçalhos de CORS obrigatórios (os cabeçalhos Origin e Access-Control-Request-Method), o serviço responderá com o código de status 400 (Solicitação incorreta).

Observe que uma solicitação de simulação será avaliada em relação ao serviço (blob, fila e tabela) e não em relação ao recurso solicitado. O proprietário da conta deve ter habilitado CORS como parte das propriedades do serviço de conta para que a solicitação seja bem-sucedida.

Quando a solicitação de simulação for aceita uma vez e a resposta for retornada, o navegador despachará a solicitação real em relação ao recurso de armazenamento. O navegador negará a solicitação real imediatamente se a solicitação de simulação for descartada.

A solicitação real será tratada como a solicitação normal em relação ao serviço de armazenamento. A presença do cabeçalho Origin indica que a solicitação é uma solicitação de CORS e o serviço verificará as regras de CORS correspondentes. Se a correspondência for encontrada, os cabeçalhos Access-Control serão adicionados à resposta e enviados de volta ao cliente. Se uma correspondência não for encontrada, os cabeçalhos Access-Control CORS não serão retornados.

As regras de CORS são definidas no nível de serviço, de modo que você precisa habilitar ou desabilitar CORS para cada serviço (Blob, Fila e Tabela). Por padrão, CORS está desabilitado para cada serviço. Para habilitar CORS, você precisará definir as propriedades de serviço adequadas usando a versão 2013-08-15 ou posterior e adicionar as regras de CORS às propriedades do serviço. Para obter detalhes sobre como habilitar ou desabilitar CORS para um serviço e como definir regras de CORS, consulte Definir propriedades do serviço Blob, Definir propriedades do serviço Tabela e Definir propriedades do serviço Fila.

Aqui está um exemplo de uma única regra de CORS, especificado por uma operação de definição das propriedades do serviço:

<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>

Cada elemento incluído na regra de CORS é descrito abaixo:

  • AllowedOrigins: Os domínios de origem que têm permissão para fazer uma solicitação no serviço de armazenamento por meio de CORS. O domínio de origem é o domínio no qual a solicitação se originou. Observe que a origem deve ser uma correspondência exata entre maiúsculas e minúsculas com a origem que a idade do usuário envia ao serviço. Você também pode usar o caractere curinga '*' para permitir que todos os domínios de origem façam solicitações por CORS. No exemplo anterior, os domínios http://www.contoso.com e http://www.fabrikam.com podem fazer solicitações em relação ao serviço usando CORS.

  • AllowedMethods: Os métodos (verbos de solicitação de HTTP) que o domínio de origem pode usar para uma solicitação de CORS. No exemplo anterior, somente solicitações PUT e GET são permitidas.

  • AllowedHeaders: Os cabeçalhos de solicitação que o domínio de origem pode especificar na solicitação de CORS. No exemplo anterior, todos os cabeçalhos de metadados que começam com x-ms-meta-data, x-ms-meta-target e x-ms-meta-abc são permitidos. Observe que o caractere curinga '*' indica que todos os cabeçalhos que começam com o prefixo especificado são permitidos.

  • ExposedHeaders: Os cabeçalhos de resposta que podem ser enviados em resposta à solicitação de CORS e expostos pelo navegador para o emissor da solicitação. No exemplo anterior, o navegador é instruído para expor todos os cabeçalhos que começam com x-ms-meta.

  • MaxAgeInSeconds: A quantidade máxima de tempo que um navegador deve armazenar em cache a solicitação de simulação OPTIONS.

Os serviços de armazenamento do Windows Azure dão suporte à especificação de cabeçalhos prefixados para elementos AllowedHeaders e ExposedHeaders. Para permitir uma categoria de cabeçalhos, você poderá especificar um prefixo comum a essa categoria. Por exemplo, especificar x-ms-meta* como um cabeçalho prefixado estabelece uma regra que corresponderá todos os cabeçalhos que começarem com x-ms-meta.

As seguintes limitações também se aplicam a regras de CORS:

  • Você pode especificar até cinco regras de CORS por serviço de armazenamento (Blob, Tabela e Fila).

  • O tamanho máximo de todas as configurações de regras de CORS na solicitação, excluindo as marcas XML, não deve exceder 2 KB.

  • O comprimento de um cabeçalho permitido, cabeçalho exposto ou origem permitida não deve exceder 256 caracteres.

  • Os cabeçalhos permitidos e os cabeçalhos ser expostos podem ser:

    • Cabeçalhos literais, onde o nome exato do cabeçalho é fornecido, como x-ms-meta-processed. Um máximo de 64 cabeçalhos literais pode ser especificado na solicitação.

    • Cabeçalhos prefixados, onde um prefixo do cabeçalho é fornecido, como x-ms-meta-data*. Especificar um prefixo dessa maneira permite ou expõe qualquer cabeçalho que comece com o prefixo especificado. Um máximo de dois cabeçalhos prefixados pode ser especificado na solicitação.

  • Os métodos (ou os verbos HTTP) especificados no elemento AllowedMethods devem estar de acordo com os métodos suportados pelas APIs do serviço de armazenamento do Windows Azure. Os métodos com suporte são DELETE, GET, HEAD, MERGE, POST, OPTIONS e PUT.

Quando um serviço de armazenamento recebe uma solicitação de simulação ou real, ele avalia que a solicitação com base nas regras de CORS estabelecida para o serviço por uma operação de definição das propriedades do serviço. As regras de CORS são avaliadas na ordem na qual foram definidas no corpo da solicitação da operação de definição das propriedades do serviço.

As regras de CORS são avaliadas da seguinte maneira:

  1. Primeiro, o domínio de origem da solicitação é verificado nos domínios listados para o elemento AllowedOrigins. Se o domínio de origem estiver incluído na lista ou se todos os domínios forem permitidas com o caractere curinga '*', a avaliação de regras será continuada. Se o domínio de origem não estiver incluído, a solicitação falhará.

  2. Em seguida, o método (ou verbo de HTTP) da solicitação é verificado em relação aos métodos listados no elemento AllowedMethods. Se o método estiver incluído na lista, as regras avaliação serão continuadas; caso contrário, a solicitação falhará.

  3. Se a solicitação corresponder a uma regra em seu domínio de origem e seu método, essa regra estará selecionada para processar a solicitação e nenhuma regra adicional será avaliada. Antes que a solicitação possa ser bem-sucedida, porém, todos os cabeçalhos especificados na solicitação serão verificados em relação aos cabeçalhos listados no elemento AllowedHeaders. Se os cabeçalhos enviados não corresponderem aos cabeçalhos permitidos, a solicitação falhará.

Como as regras são processadas na ordem em que estão presentes no corpo da solicitação, as práticas recomendadas são para especificar as regras mais restritivas em relação às origens primeiro na lista, de modo que elas sejam avaliadas primeiro. Especifique as regras que são menos restritivos – por exemplo, uma regra para permitir todas as origens – no final da lista.

O exemplo a seguir mostra um corpo de solicitação parcial para a operação para definir as regras de CORS para os serviços de armazenamento. Consulte Definir propriedades do serviço Blob, Definir propriedades do serviço Fila e Definir propriedades do serviço Tabela para obter detalhes sobre como construir a solicitação.

<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>

Em seguida, considere as seguintes solicitações de CORS:

 

Request

Response

Method

Origin

Request headers

Rule Match

Result

PUT

http://www.contoso.com

x-ms-blob-content-type

A primeira regra

Êxito

GET

http://www.contoso.com

x-ms-blob-content-type

A segunda regra

Êxito

GET

http://www.contoso.com

x-ms-client-request-id

A segunda regra

Falha

A primeira solicitação corresponde à primeira regra – o domínio de origem corresponde às origens permitidas, o método corresponde aos métodos permitidos e o cabeçalho corresponde aos cabeçalhos permitidos – e, portanto, tem êxito.

A segunda solicitação não corresponde à primeira regra porque o método não corresponde aos métodos permitidos. No entanto, ela corresponde à segunda regra, portanto, tem êxito.

A terceira solicitação corresponde à segunda regra em seu domínio e método de origem, de modo que nenhuma regra adicional será avaliada. No entanto, o cabeçalho x-ms-client-request-id não é permitido pela segunda regra e, portanto, a solicitação falha, independentemente do fato de que a semântica da terceira regra teria permitido ter êxito.

noteObservação
Embora este exemplo mostre uma regra menos restritiva antes de uma mais restritiva, geralmente a prática recomendada é listar primeiro as regras mais restritivas.

O cabeçalho Vary é um cabeçalho de HTTP/1.1 padrão que consiste em um conjunto de campos de cabeçalho de solicitação que recomendam o agente do navegador ou de usuário sobre os critérios selecionados pelo servidor para processar a solicitação. O cabeçalho Vary é usado principalmente para armazenamento em cache por proxies, navegadores e CDNs, que o usam para determinar como a resposta deve ser armazenada em cache. Para obter detalhes, consulte a especificação do Cabeçalho Vary.

Quando o navegador ou outro agente de usuário armazena em cache a resposta de uma solicitação de CORS, o domínio de origem é armazenado em cache como a origem permitida. Quando um segundo domínio emite a mesma solicitação para um recurso de armazenamento enquanto o cache está ativo, o agente de usuário recupera o domínio armazenado em cache da origem. O segundo domínio não corresponde ao domínio armazenado em cache; portanto, a solicitação falhará quando teria êxito de outra forma. Em determinados casos, o armazenamento do Windows Azure define o cabeçalho Vary como Origin para instruir o agente do usuário para enviar a solicitação subsequente de CORS para o serviço quando o domínio de solicitação difere da origem armazenada em cache.

O armazenamento do Windows Azure define o cabeçalho Vary como Origin para solicitações atuais de GET/HEAD nos seguintes casos:

  • Quando a origem da solicitação corresponde exatamente à origem permitida definida por uma regra de CORS. Para ser uma correspondência exata, as regras de CORS não podem conter um caractere curinga '*'.

  • Não há nenhuma regra que corresponde à origem da solicitação, mas a regra de CORS é habilitada para o serviço de armazenamento.

Nos casos em que uma solicitação de GET/HEAD corresponde à regra de CORS que permite todas as origens, a resposta indica que todas as origens são permitidas, e o cache do agente do usuário permite solicitações subsequentes de qualquer domínio de origem quando o cache está ativo.

Observe que, para solicitações que usam métodos diferentes de GET/HEAD, os serviços de armazenamento não definirão o cabeçalho Vary, contanto que as respostas a esses métodos não sejam armazenadas em cache por agentes de usuário.

A tabela a seguir indica como o armazenamento do Windows Azure atenderá solicitações de GET/HEAD com base nos casos previamente mencionados:

 

Solicitação

Configuração da conta e resultado da avaliação de regras

Resposta

Cabeçalho da origem presente na solicitação

Regras de CORS especificadas para esse serviço

A regra de correspondência existe que permite todas as origens (*)

A regra de correspondência existe para a correspondência exata da origem

A resposta inclui o cabeçalho Vary definido como Origin

A resposta inclui Access-Control-Allowed-Origin: "*"

A resposta inclui Access-Control-Exposed-Headers

Não

Não

Não

Não

Não

Não

Não

Não

Sim

Não

Não

Sim

Não

Não

Não

Sim

Sim

Não

Não

Sim

Sim

Sim

Não

Não

Não

Não

Não

Não

Sim

Sim

Não

Sim

Sim

Não

Sim

Sim

Sim

Não

Não

Sim

Não

Não

Sim

Sim

Sim

Não

Não

Sim

Sim

As solicitações de simulação com êxito são faturadas se você tiver habilitado CORS para qualquer serviço de armazenamento para sua conta (chamando Definir propriedades do serviço Blob, Definir propriedades do serviço Fila ou Definir propriedades do serviço Tabela). Para minimizar encargos, defina o elemento MaxAgeInSeconds nas regras de CORS com um valor grande de forma que o agente do usuário armazene em cache a solicitação.

As solicitações de simulação malsucedidas não serão cobradas.

Consulte também

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft