Partilhar via

Diretrizes de Retíduo ACS

  • Artigo

Atualizado: 6 de julho de 2015

Aplica-se a: Azure

Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como Controlo de Acesso Service ou ACS) suporta uma série de diferentes pontos finais de emissão e gestão para os quais os clientes podem enviar pedidos simbólicos. Este tópico define orientações para implementar a lógica de relemissão quando os pedidos simbólicos falham.

Cenários Error-Handling

As falhas de pedido de token que devolvem códigos de erro da série HTTP 500 normalmente respondem a recauchutagens. Em alguns cenários, o cliente é uma aplicação ou serviço que faz pedidos automatizados à ACS. Noutros cenários, como a federação baseada na Web que utiliza o protocolo WS-Federation, o cliente é um navegador web e o utilizador final deve voltar a tentar a operação manualmente. Este tópico abrange cenários de tratamento de erros em que o cliente é uma aplicação ou serviço.

Os cenários incluem:

Diretrizes de Retírição

As seguintes orientações explicam como implementar a lógica de retírimento nos cenários de tratamento de erros.

Orientação #1: Implementar lógica de repetição com base em respostas de erro da série HTTP 500

A lógica de relemissão é fortemente recomendada quando o ACS devolve erros da série HTTP 500. A lista seguinte inclui exemplos de erros típicos da série HTTP 500.

  • ERRO HTTP 500 - Erro interno do servidor

  • ERRO HTTP 502 - Bad Gateway

  • HTTP Error 503 - Serviço Indisponível

  • HTTP Error 504 - Gateway Timeout

Embora os códigos HTTP individuais possam ser enumerados na lógica de relagem, é suficiente invocar uma lógica de relagem se algum erro da série HTTP 500 for devolvido.

A lógica de reagem deve ser desencadeada por códigos de erro HTTP, tais como HTTP 504 (tempo limite de servidor externo) e não por códigos de erro ACS, como ACS90005. Os códigos de erro ACS são informativos e sujeitos a alterações.

Normalmente, a lógica de relagem não é recomendada quando os códigos de erro da série HTTP 400 são devolvidos. Um código de resposta a erros HTTP de série 400 da ACS significa que o pedido é inválido e precisa de ser revisto. Uma exceção é o código de erro 429 ("Demasiados pedidos"), o que indica que o espaço de nome excedeu o limite de taxa de pedido de token por um período prolongado. Para 429 erros, as retrígios com um temporizador de backoff podem resolver o atraso imediato do pedido de token até que o administrador tenha tempo para rever e rever a distribuição da carga de trabalho do espaço de nome. Para mais informações, consulte as Limitações de Serviço ACS.

Orientação #2: As retróscamos devem utilizar um temporizador de back-off para um controlo de fluxo ideal

Quando um cliente recebe um erro da série HTTP 500, o cliente deve aguardar um período de tempo especificado antes de voltar a tentar o pedido. Para obter melhores resultados, recomenda-se que este período de tempo aumente com cada relemisso subsequente. Esta abordagem permite que os erros transitórios sejam resolvidos rapidamente, ao mesmo tempo que otimiza a taxa de pedido para problemas transitórios de rede ou servidor que demoram mais tempo a ser resolvidos.

Por exemplo, utilize um temporizador exponencial de recuo onde o atraso antes de voltar a tentar aumenta exponencialmente a cada instância, como Retry 1: 1 segundo, Retry 2: 2 segundos, Retry 3: 4 segundos, e assim por diante.

Ajuste o número de retrações e o tempo entre cada tentativa com base nos requisitos de experiência do utilizador. No entanto, recomendamos até cinco retrófas durante um período de cinco minutos. Falhas causadas por um intervalo demoram mais tempo a resolver.

Orientação #3: Verifique se o item não existe antes de tentar criá-lo ou eliminá-lo

Ao realizar operações de criação ou eliminação com o Serviço de Gestão ACS, como a criação de uma nova aplicação de partidos dependentes ou a eliminação de uma regra, a lógica de recandidatura deve consultar se o item existe antes de realizar a operação. Em algumas circunstâncias, como uma falha de rede transitória que ocorre durante a entrega da resposta do servidor, uma operação de criação ou eliminação pode ter sucesso mesmo quando o cliente obtém uma resposta de erro.

Se uma operação de criação for novamente julgada sem verificar a existência do item, podem ser criados itens duplicados. , Além disso, o sistema pode devolver um erro HTTP 400 se o item tiver de ser único.

Se uma operação de eliminação for novamente julgada sem verificar a existência do item, o sistema poderá devolver um erro HTTP 400 quando não conseguir encontrar o item.

Consulte também

Conceitos

Códigos de erro ACS
Limitações de serviços ACS
Serviço de Gestão ACS
Como: Solicitar um Token da ACS através do Protocolo de WRAP OAuth
Amostra de código: Autenticação do Certificado OAuth 2.0
Índice de Orientações ACS