Mécanisme de limitation 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 à leur business case.

L’authentification par mot de passe introduit un mécanisme de limitation pour assurer une répartition é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 Pass 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 implémentations peuvent avoir une implémentation rudimentaire et pourraient inonder le service de requêtes d’API inutiles, que ce soit accidentellement ou non, ce qui pourrait entraîner des ralentissements ou des problèmes de capacité pour d’autres utilisateurs et utilisatrices.

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

Introduction du ralentissement

L'authentification Pass est basée sur l'identification de l'utilisateur et un algorithme de limitation du taux de compartiments de jetons avec des valeurs prédéfinies pour contrôler l'accès de chaque utilisateur à notre API.

Mécanisme d'identification de dispositif

Le mécanisme de limitation proposé utilise individuellement les dispositifs identifiés, à 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 ici.

Limites et points d’entrée réels throttling-mechanism-limits

Actuellement, la limite par défaut autorise un maximum de 1 requête par seconde, avec un rafale initiale de 10 requêtes (autorisation unique sur la première interaction du client identifié, ce qui devrait permettre à l’initialisation de se terminer correctement). Cela ne devrait pas affecter les analyses de rentabilisation standard de tous nos clients.

Le mécanisme de limitation sera activé sur les points d’entrée suivants :

Désambiguïté de l’implémentation de SDK

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

setRequestor

Une fois la limite de limitation atteinte à l’aide de setRequestor fonction du SDK, le SDK renvoie un code d’erreur CFG429 par le biais errorHandler rappel .

getAuthorization

Une fois la limite de limitation atteinte à l’aide de getAuthorization fonction du SDK, le SDK renvoie un code d’erreur Z100 par le biais errorHandler rappel .

checkPreauthorizedResources

Une fois la limite de limitation atteinte à l’aide de checkPreauthorizedResources fonction du SDK, le SDK renvoie un code d’erreur P100 par le biais errorHandler rappel .

getMetadata

Une fois la limite de limitation atteinte à l’aide de getMetadata fonction du SDK, le SDK renvoie une réponse vide par le biais d’setMetadataStatus rappel .

Pour chaque détail d’implémentation spécifique, reportez-vous à la documentation spécifique de SDK.

Modifications de la réponse de l’API et réponse throttling-mechanism-response

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

La limitation 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 clientes doivent gérer de manière appropriée 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

Transmettre l’en-tête X-Forwarded-For

Les clients qui utilisent une implémentation 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 suite à l’API Pass Authentication.

Voir ici pour plus d’informations.

Réaction au nouveau code de réponse

Les clients qui utilisent une implémentation personnalisée (y compris de serveur à serveur) pour interagir avec l’API d’authentification Pass doivent s’assurer que tout appel ultérieur effectué après réception d’une demande 429 Too many inclut 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 de limitation