Mecanismo de limitação throttling-mechanism

Todos os clientes do Pass Authentication precisam acessar a API do Pass Authentication para cada um de seus usuários, de acordo com as instruções e o business case.

A Autenticação de aprovação introduz um mecanismo de limitação para garantir a distribuição equitativa de recursos entre os usuários de nossos clientes.

Esse mecanismo é importante por alguns motivos:

Visão geral do mecanismo mechanism-overview

Implementações do cliente

A Autenticação de aprovação fornece diretrizes e SDK para interagir com a API, mas não controla como o cliente a usa. Algumas implementações podem ter uma implementação rudimentar e podem inundar o serviço com solicitações desnecessárias de API, seja acidentalmente ou não, o que pode significar que outros usuários tenham lentidão ou problemas de capacidade.

O próprio serviço deve ser capaz de lidar com qualquer capacidade razoável. Mas não importa o desempenho ou a escalabilidade de um serviço, há sempre limites. Dessa forma, o serviço deve ter limites configurados para o número de chamadas aceitas em um intervalo de tempo específico.

Introdução à limitação

A autenticação de aprovação é baseada na identificação do usuário e em um algoritmo de limitação da taxa do token bucket com valores predefinidos para controlar o acesso do dispositivo de cada usuário à nossa API.

Mecanismo de identificação do dispositivo

O mecanismo de limitação proposto usa os dispositivos identificados individualmente, com a ajuda do cabeçalho "X-Forwarded-For". Os limites serão aplicados da mesma forma para cada dispositivo.

Atualizações necessárias

As implementações de servidor para servidor devem encaminhar os endereços IP do cliente usando o mecanismo de cabeçalho "X-Forwarded-For".

Você pode encontrar mais detalhes sobre como passar o cabeçalho X-Forwarded-For aqui.

Limites e endpoints reais

Atualmente, o limite padrão permite no máximo 1 solicitação por segundo, com uma intermitência inicial de 10 solicitações (permissão única na primeira interação do cliente identificado, o que deve permitir que a inicialização seja concluída com êxito). Isso não deve afetar nenhum caso comercial normal em todos os nossos clientes.

O mecanismo de limitação será habilitado nos seguintes pontos de extremidade:

Desambiguação da implementação do SDK

Como os clientes que usam a Autenticação Adobe Pass fornecidos pelos SDKs não estão interagindo explicitamente com nenhum endpoint, esta seção apresentará as funções conhecidas, como elas se comportam ao encontrar uma resposta de limitação e as ações que devem ser tomadas.

setRequestor

Ao atingir o limite de aceleração usando a função setRequestor do SDK, o SDK retornará um código de erro CFG429 por meio do retorno de chamada errorHandler.

getAuthorization

Ao atingir o limite de aceleração usando a função getAuthorization do SDK, o SDK retornará um código de erro Z100 pela chamada de retorno errorHandler.

checkPreauthorizedResources

Ao atingir o limite de aceleração usando a função checkPreauthorizedResources do SDK, o SDK retornará um código de erro P100 pela chamada de retorno errorHandler.

getMetadata

Ao atingir o limite de aceleração usando a função getMetadata do SDK, o SDK retornará uma resposta vazia por meio do retorno de chamada setMetadataStatus.

Para cada detalhe de implementação específico, consulte a documentação do SDK.

Alterações na resposta da API e resposta

Quando identificamos que o limite foi violado, marcaremos essa solicitação com um status de resposta específico (HTTP 429 Demasiadas solicitações), instruindo que você tenha consumido todos os tokens atribuídos ao dispositivo do usuário (endereço IP) para o intervalo de tempo.

A limitação expira após um segundo das primeiras 429 respostas. Cada aplicativo que recebe uma resposta 429 deve aguardar pelo menos 1 segundo antes de gerar uma nova solicitação.

Todos os aplicativos do cliente devem lidar adequadamente com a resposta "429 muitas solicitações".

Esta é uma amostra de mensagem de resposta 429:

HTTP/2 429
date: Tue, 20 Feb 2024 11:21:53 GMT
content-type: text/html
content-length: 166
set-cookie: AWSALB=Btl/GzifUpMhUh+TQK63kU4i+gcJOIvAICVLnHTWt5pkrevNsMSQ5DMwM9KlRkNQ0UlXHIDbQoxDua0oVYYFKC8PDwxQjOuuRzxX2fozM+Jcazl2DSfaR7hU2mt2; Expires=Tue, 27 Feb 2024 11:21:53 GMT; Path=/
set-cookie: AWSALBCORS=Btl/GzifUpMhUh+TQK63kU4i+gcJOIvAICVLnHTWt5pkrevNsMSQ5DMwM9KlRkNQ0UlXHIDbQoxDua0oVYYFKC8PDwxQjOuuRzxX2fozM+Jcazl2DSfaR7hU2mt2; Expires=Tue, 27 Feb 2024 11:21:53 GMT; Path=/; SameSite=None; Secure
server: openresty
access-control-allow-credentials: true
access-control-allow-methods: POST,GET,OPTIONS,DELETE
access-control-allow-headers: ap_11,ap_42,ap_z,ap_19,ap_21,ap_23,authorization,content-type,pass_sfp,AP-Session-Identifier,AP-Device-Identifier,AP-SDK-Identifier,X-Device-Info
access-control-expose-headers: pass_sfp,Authzf-Error-Code,Authzf-Sub-Error-Code,Authzf-Error-Details
p3p: CP="NOI DSP COR CURa ADMa DEVa OUR BUS IND UNI COM NAV STA"

<html>
<head><title>429 Too Many Requests</title></head>
<body>
<center><h1>429 Too Many Requests</h1></center>
<hr><center>openresty</center>
</body>
</html>

Impacto e alterações necessárias

Passando o cabeçalho X-Forwarded-For

Os clientes que usam uma implementação personalizada (incluindo servidores para servidores) para interagir com a API de autenticação de passagem devem garantir que possam capturar o endereço IP do usuário e encaminhá-lo corretamente, usando o cabeçalho X-Forwarded-For além da API de autenticação de passagem.

Consulte aqui para obter mais detalhes.

Reação a novo código de resposta

Os clientes que usam uma implementação personalizada (incluindo as de servidor para servidor) para interagir com a API de autenticação de passagem devem garantir que qualquer chamada subsequente feita após receber um número excessivo de solicitações 429 inclua um período de espera mínimo de 1 segundo. Esse período de espera garante uma oportunidade de alterar esse mecanismo e obter uma resposta comercial válida.

Exemplo de cenário para limitação