Diretrizes para repetição de ACS

  • Artigo

Atualizado em: 6 de julho de 2015

Aplica-se ao Azure

Microsoft Azure Active Directory Controle de Acesso (também conhecido como serviço de Controle de Acesso ou ACS) dá suporte a vários pontos de extremidade de gerenciamento e emissão de tokens diferentes para os quais os clientes podem enviar solicitações de token. Este tópico define as diretrizes para implementação da lógica de repetição quando as solicitações de token falham.

Cenários de tratamento de erros

As falhas de solicitação de token que retornam códigos de erro HTTP 500 normalmente respondem a repetições. Em alguns cenários, o cliente é um aplicativo ou serviço que faz solicitações automatizadas para o ACS. Em outros cenários, como no caso da federação baseada na Web, que usa o protocolo WS-Federation, o cliente é um navegador e o usuário final deve repetir a operação manualmente. Este tópico aborda os cenários de tratamento de erros nos quais o cliente é um aplicativo ou um serviço.

Esses cenários incluem:

Diretrizes sobre repetição

As diretrizes a seguir explicam como implementar a lógica de repetição nos cenários de tratamento de erros.

Diretriz nº 1: implementar lógica de repetição com base em respostas de erro da série HTTP 500

A lógica de repetição é altamente recomendada quando o ACS retorna erros da série HTTP 500. A lista a seguir inclui cenários de erros HTTP 500 típicos.

  • Erro HTTP 500 - Erro interno do servidor

  • Erro HTTP 502 - Gateway Incorreto

  • Erro HTTP 503 - Serviço indisponível

  • Erro HTTP 504 – Tempo limite do gateway

Embora códigos HTTP individuais possam ser enumerados na lógica de repetição, é suficiente invocar a lógica de repetição se algum erro HTTP 500 for exibido.

A lógica de repetição deve ser disparada por códigos de erro HTTP, como HTTP 504 (tempo limite do servidor externo) e não por códigos de erro ACS, como ACS90005. Os códigos de erro do ACS são informativos e estão sujeitos a alteração.

Normalmente, a lógica de repetição não é recomendável quando são retornados códigos de erro da série HTTP 400. Um código de resposta de erro da série HTTP 400 do ACS significa que a solicitação é inválida e precisa ser revisada. Uma exceção é o código de erro 429 ("Excesso de solicitações"), que indica que o namespace excedeu o limite da taxa de solicitação de token por um longo período. No caso de erros 429, as repetições com um temporizador de retirada podem resolver a lista de pendências imediatas da solicitação de token até o administrador ter tempo de verificar e analisar a distribuição de carga de trabalho do namespace. Para obter mais informações, consulte Limitações do serviço ACS.

Diretriz nº 2: as repetições devem usar um temporizador de back-off para o controle de fluxo ideal

Quando um cliente recebe um erro HTTP 500, ele deve aguardar por um determinado período de tempo antes de repetir a solicitação. Para obter melhores resultados, é recomendável que esse período aumente a cada repetição subsequente. Essa abordagem permite que os erros transitórios sejam resolvidos rapidamente ao otimizar a taxa de solicitação para problemas transitórios de rede ou de servidor que demorem mais para serem resolvidos.

Por exemplo, use um temporizador de retirada exponencial onde o atraso antes da repetição aumente com cada instância, como Repetir 1:1 segundo, Repetir 2:2 segundos, Repetir 3:4 segundos e assim por diante.

Ajuste o número de repetições e o tempo entre cada repetição com base em seus requisitos de experiência do usuário. No entanto, é recomendável até cinco repetições em um período de cinco minutos. As falhas causadas por um tempo limite levam mais tempo para serem resolvidas.

Diretriz nº 3: verifique se o item não existe antes de tentar criá-lo ou excluí-lo

Ao executar operações de criação ou exclusão com o Serviço de Gerenciamento do ACS, como criar um novo aplicativo de terceira parte confiável ou excluir uma regra, a lógica de repetição deve consultar se o item existe antes de executar a operação. Em algumas circunstâncias, como uma falha transitória de rede que ocorre durante a entrega da resposta do servidor, uma operação de criação ou exclusão pode ter êxito mesmo quando o cliente recebe uma resposta de erro.

Se uma operação de criação for repetida sem a verificação da existência do item, itens duplicados poderão ser criados. Além disso, o sistema pode retornar um erro HTTP 400 se o item for único.

Se uma operação de exclusão for repetida sem a verificação da existência do item, o sistema poderá retornar um erro HTTP 400 quando não conseguir encontrar o item.

Consulte Também

Conceitos

Códigos de erro do ACS
Limitações do serviço ACS
Serviço de Gerenciamento ACS
Como solicitar um token do ACS por meio do protocolo OAuth WRAP
Exemplo de código: Autenticação de Certificado OAuth 2.0
Índice das diretrizes do ACS