Mécanisme de ralentissement throttling-mechanism

Tous les clients Pass Authentication doivent pouvoir accéder à l’API Pass Authentication pour chacun de leurs utilisateurs, conformément aux instructions et à leurs analyses de cas.

L’authentification par col introduit un mécanisme de limitation pour assurer une distribution équitable des ressources entre les utilisateurs de nos clients.

Ce mécanisme est important pour plusieurs raisons :

Présentation du mécanisme mechanism-overview

Implémentations client

L’authentification par transmission fournit des instructions et un SDK pour interagir avec l’API, mais ne contrôle pas la manière dont le client l’utilise. Certaines mises en oeuvre peuvent avoir une mise en oeuvre rudimentaire et peuvent inonder le service de requêtes d’API inutiles, accidentellement ou non, ce qui peut entraîner des ralentissements ou des problèmes de capacité pour d’autres utilisateurs.

Le service lui-même doit être en mesure de gérer toute capacité raisonnable. Mais quel que soit l’évolutivité ou les performances d’un service, il y a toujours des limites. Par conséquent, les limites du nombre d’appels acceptés doivent être configurées pour le service dans un intervalle de temps spécifique.

Présentation du ralentissement

L’authentification par transmission est basée sur l’identification de l’utilisateur et un algorithme de limitation de débit de jeton avec des valeurs prédéfinies pour contrôler l’accès de chaque appareil d’utilisateur à notre API.

Mécanisme d'identification des périphériques

Le mécanisme de ralentissement proposé utilise les périphériques identifiés individuellement, à l’aide de l’en-tête "X-Forwarded-For". Les limites seront appliquées de la même manière pour chaque appareil.

Mises à jour requises

Les implémentations serveur à serveur doivent transférer les adresses IP de leur client à l’aide du mécanisme d’en-tête "X-Forwarded-For".

Vous trouverez plus d’informations sur la manière de transmettre l’en-tête X-Forwarded-For here.

Limites et points de fin réels

Actuellement, la limite par défaut autorise un maximum de 1 requête par seconde, avec une première rafale de 3 requêtes (allocation unique lors de la première interaction du client identifié, ce qui devrait permettre à l’initialisation de se terminer avec succès). Cela ne devrait affecter aucune analyse de performances classique de tous nos clients.

Le mécanisme de ralentissement sera activé sur les points de terminaison suivants :

clarification de l'implémentation du SDK

Les clients qui utilisent les SDK fournis par l’authentification Adobe Pass n’interagissent pas explicitement avec les points de terminaison, cette section présente les fonctions connues, leur comportement en cas de réponse de ralentissement et les actions à entreprendre.

setRequestor

Lorsque vous atteignez la limite de ralentissement en utilisant setRequestor à partir du SDK, le SDK renvoie un code d’erreur CFG429 via errorHandler rappel.

getAuthorization

Lorsque vous atteignez la limite de ralentissement en utilisant getAuthorization à partir du SDK, le SDK renvoie un code d’erreur Z100 via errorHandler rappel.

checkPreauthorizedResources

Lorsque vous atteignez la limite de ralentissement en utilisant checkPreauthorizedResources à partir du SDK, le SDK renvoie un code d’erreur P100 via errorHandler rappel.

getMetadata

Lorsque vous atteignez la limite de ralentissement en utilisant getMetadata à partir du SDK, le SDK renvoie une réponse vide via setMetadataStatus rappel.

Pour chaque détail de mise en oeuvre spécifique, reportez-vous à la documentation spécifique du SDK.

Modifications et réponse de la réponse de l’API

Lorsque nous identifions que la limite est atteinte, nous marquons cette requête avec un état de réponse spécifique (requêtes HTTP 429 Too many), indiquant que vous avez consommé tous les jetons affectés à l’appareil de l’utilisateur (adresse IP) pendant l’intervalle de temps.

Le ralentissement expire après une seconde des 429 premières réponses. Chaque application qui reçoit une réponse 429 doit attendre au moins 1 seconde avant de générer une nouvelle requête.

Toutes les applications client doivent gérer correctement la réponse "429 Too many requests".

Voici un exemple de message de réponse 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>

Impact et modifications requises

Transfert de l’en-tête X-Forwarded-For

Les clients qui utilisent une mise en oeuvre personnalisée (y compris de serveur à serveur) pour interagir avec l’API Pass Authentication doivent s’assurer qu’ils peuvent capturer leur adresse IP utilisateur et la transférer correctement, en utilisant l’en-tête X-Forwarded-For plus loin dans l’API Pass Authentication.

Voir here pour plus d’informations.

Réaction au nouveau code de réponse

Les clients qui utilisent une mise en oeuvre personnalisée (y compris celle du serveur à serveur) pour interagir avec l’API Pass Authentication doivent s’assurer que tout appel ultérieur effectué après la réception d’une demande 429 Too Many comprend une période d’attente d’au moins 1 seconde. Cette période d’attente permet de modifier ce mécanisme et d’obtenir une réponse commerciale valide.

Exemple de scénario pour le ralentissement