Meccanismo di limitazione throttling-mechanism

Tutti i clienti di Autenticazione di tipo Pass devono essere in grado di accedere all’API di autenticazione di tipo Pass per ciascuno dei loro utenti, in base alle istruzioni e al loro caso aziendale.

L’autenticazione pass introduce un meccanismo di limitazione per garantire un’equa distribuzione delle risorse tra gli utenti dei nostri clienti.

Questo meccanismo è importante per alcuni motivi:

Panoramica sul meccanismo mechanism-overview

Implementazioni client

Pass Authentication fornisce linee guida e SDK per l’interazione con l’API, ma non controlla come il cliente la utilizza. Alcune implementazioni possono avere un’implementazione rudimentale e potrebbero inondare il servizio di richieste API non necessarie, accidentalmente o meno, potrebbe comportare rallentamenti o problemi di capacità per altri utenti.

Il servizio stesso dovrebbe essere in grado di gestire qualsiasi capacità ragionevole. Ma non importa quanto scalabile o performante sia un servizio, ci sono sempre dei limiti. Di conseguenza, il servizio deve disporre di limiti configurati per il numero di chiamate accettate entro un intervallo di tempo specifico.

Introduzione alla limitazione

L’autenticazione pass si basa sull’identificazione dell’utente e su un algoritmo di limitazione della frequenza dei bucket dei token con valori predefiniti per controllare l’accesso del dispositivo di ciascun utente all’API.

Meccanismo di identificazione del dispositivo

Il meccanismo di limitazione proposto utilizza i dispositivi identificati singolarmente, con l’aiuto dell’intestazione "X-Forwarded-For". I limiti vengono applicati nello stesso modo per ogni dispositivo.

Aggiornamenti richiesti

Le implementazioni server-to-server devono inoltrare gli indirizzi IP dei propri client utilizzando il meccanismo di intestazione "X-Forwarded-For".

Puoi trovare ulteriori dettagli su come trasmettere l’intestazione X-Forwarded-For qui.

Limiti ed endpoint effettivi

Attualmente, il limite predefinito consente un massimo di 1 richiesta al secondo., con un burst iniziale di 3 richieste (una tantum per la prima interazione del client identificato, che dovrebbe consentire il completamento dell’inizializzazione). Questo non dovrebbe influenzare nessun caso di business regolare tra tutti i nostri clienti.

Il meccanismo di limitazione verrà attivato sui seguenti endpoint:

Disambiguazione nell'implementazione dell'SDK

Poiché i client che utilizzano l’autenticazione di Adobe Pass fornita dagli SDK non interagiscono in modo esplicito con alcun endpoint, questa sezione presenta le funzioni note, il loro comportamento quando incontrano una risposta di limitazione e le azioni da intraprendere.

setRequestor

Quando si raggiunge il limite di velocità utilizzando setRequestor funzione dall’SDK, l’SDK restituirà un codice di errore CFG429 tramite errorHandler callback.

getAuthorization

Quando si raggiunge il limite di velocità utilizzando getAuthorization dall'SDK, restituirà un codice di errore Z100 tramite errorHandler callback.

checkPreauthorizedResources

Quando si raggiunge il limite di velocità utilizzando checkPreauthorizedResources dall'SDK, restituirà un codice di errore P100 tramite il comando errorHandler callback.

getMetadata

Quando si raggiunge il limite di velocità utilizzando getMetadata dall'SDK, l'SDK restituirà una risposta vuota tramite setMetadataStatus callback.

Per ogni dettaglio di implementazione specifico, consulta la documentazione SDK specifica.

Modifiche alla risposta API e risposta

Quando identifichiamo che il limite è stato superato, contrassegneremo questa richiesta con uno stato di risposta specifico (HTTP 429 Troppe richieste), indicando che hai utilizzato tutti i token assegnati al dispositivo utente (indirizzo IP) per l’intervallo di tempo.

La limitazione scade dopo un secondo delle prime 429 risposte. Ogni applicazione che riceve una risposta 429 deve attendere almeno 1 secondo prima di generare una nuova richiesta.

Tutte le applicazioni del cliente devono gestire in modo appropriato la risposta "429 Troppe richieste".

Ecco un esempio di messaggio di risposta 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>

Impatto e modifiche necessarie

Trasmissione dell’intestazione X-Forwarded-For

I clienti che utilizzano un’implementazione personalizzata (inclusi quelli da server a server) per interagire con l’API di autenticazione pass devono assicurarsi di poter acquisire l’indirizzo IP dell’utente e inoltrarlo correttamente, utilizzando l’intestazione X-Forwarded-For anche per Pass Authentication API.

Consulta qui per ulteriori dettagli.

Reazione al nuovo codice di risposta

I clienti che utilizzano un’implementazione personalizzata (incluse quelle da server a server) per interagire con l’API di autenticazione pass devono assicurarsi che qualsiasi chiamata successiva effettuata dopo la ricezione di una richiesta 429 Troppe includa un periodo di attesa minimo di 1 secondo. Questo periodo di attesa garantisce l'opportunità di modificare questo meccanismo e ottenere una risposta aziendale valida.

Esempio di scenario per la limitazione