Draaimechanisme throttling-mechanism

Alle klanten van de Authentificatie van de Voldoende moeten tot de Authentificatie API van de Voldoende voor elk van hun gebruikers, volgens instructies en hun bedrijfscase kunnen toegang hebben.

De Authentificatie van de pas introduceert een Throttling mechanisme om billijke verdeling van middelen onder de gebruikers van onze klanten te verzekeren.

Dit mechanisme is om een paar redenen belangrijk:

Overzicht van het mechanisme mechanism-overview

Clientimplementaties

De Authentificatie van de pas verstrekt richtlijnen en SDK voor het in wisselwerking staan met API maar controleert niet hoe de klant het gebruikt. Sommige implementaties kunnen een rudimentaire implementatie hebben en kunnen de service overspoelen met onnodige API-verzoeken, of dit nu per ongeluk gebeurt of niet, kan ertoe leiden dat andere gebruikers trager worden of problemen met de capaciteit ondervinden.

De dienst zelf moet elke redelijke capaciteit kunnen afhandelen. Maar hoe schaalbaar of uitvoerbaar een service ook is, er zijn altijd grenzen. Als dusdanig, moet de dienst grenzen hebben die voor het aantal toegelaten vraag binnen een specifiek tijdinterval worden gevormd.

Bezig met introduceren van vertragen

De Authentificatie van de pas is gebaseerd op gebruikersidentificatie en een symbolische algoritme van de het tariefbeperking van de emmer met vooraf bepaalde waarden om de apparatentoegang van elke gebruiker tot onze API te controleren.

Apparaatidentificatiemechanisme

Het voorgestelde vertragingsmechanisme gebruikt de geïdentificeerde apparaten individueel, met behulp van "x-Door:sturen-voor"kopbal. Limieten worden op dezelfde manier toegepast voor elk apparaat.

Vereiste updates

Server-aan-server implementaties moeten de IP van hun cliënt adressen door:sturen gebruikend het "X-Door:sturen-voor"kopbalmechanisme.

U kunt meer details op vinden hoe te om x-door:sturen-voor kopbal hierover te gaan.

Werkelijke grenswaarden en eindpunten

Momenteel, staat de standaardgrens een maximum van 1 verzoek per seconde toe, met een aanvankelijke uitbarsting van 10 verzoeken (eenmalig toelage op de eerste interactie van de geïdentificeerde cliënt, die initialisering zou moeten toestaan om met succes te beëindigen). Dit zou geen regelmatige bedrijfsgeval over al onze klanten moeten beïnvloeden.

Het vertragingsmechanisme zal op de volgende eindpunten worden toegelaten:

SDK-implementatie

Aangezien de cliënten die de Authentificatie gebruiken van Adobe Pass verstrekte SDKs niet uitdrukkelijk met om het even welke eindpunten in wisselwerking staan, zal deze sectie de bekende functies presenteren, hoe zij zich wanneer het ontmoeten van een vertragingsreactie, en de acties gedragen die zouden moeten worden genomen.

setRequestor

Wanneer de snelheidslimiet is bereikt met behulp van de functie setRequestor van de SDK, retourneert de SDK een CFG429-foutcode via errorHandler callback.

getAuthorization

Wanneer de vertragingslimiet is bereikt met behulp van de functie getAuthorization van de SDK, retourneert de SDK een Z100-foutcode via errorHandler callback.

checkPreauthorisedResources

Wanneer de snelheidslimiet is bereikt met behulp van de functie checkPreauthorizedResources van de SDK, retourneert de SDK een P100-foutcode via de errorHandler callback.

getMetadata

Wanneer de snelheidslimiet is bereikt met behulp van de functie getMetadata van de SDK, retourneert de SDK een lege reactie via setMetadataStatus callback.

Raadpleeg de specifieke SDK-documentatie voor elke specifieke implementatiedetails.

Wijzigingen in API-reactie en reactie

Wanneer wij identificeren dat de grens wordt geschonden, zullen wij dit verzoek met een specifieke reactiestatus (HTTP 429 Te Vele Verzoeken) merken, die dat u alle tokens hebt verbruikt die aan het gebruikersapparaat (IP adres) voor het tijdinterval worden toegewezen.

De vertraging verloopt na één seconde van de eerste 429 reacties. Elke toepassing die een reactie van 429 ontvangt, moet minstens 1 seconde wachten alvorens een nieuw verzoek te produceren.

Alle klantentoepassingen zouden de "429 Te Vele antwoorden van Verzoeken"geschikt moeten behandelen.

Hier volgt een voorbeeld van een 429-antwoordbericht:

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>

Effect en vereiste wijzigingen

X-Forwarded-For-header doorgeven

Klanten die een aangepaste implementatie (inclusief server-naar-server) gebruiken om te communiceren met de API voor controle van de controle van de controle moeten ervoor zorgen dat zij hun IP-adres van de gebruiker kunnen vastleggen en het correct kunnen doorsturen, met behulp van de X-Forwarded-For-header die verder gaat naar de API voor verificatie van de controle van de controle van de controle.

Zie hiervoor meer details.

Reageren op nieuwe antwoordcode

De klanten die een douaneimplementatie (met inbegrip van server-aan-server degenen) gebruiken om met de Authentificatie API van de Voldoende te communiceren zouden ervoor moeten zorgen dat om het even welke verdere vraag die na het ontvangen van 429 Te veel Verzoeken wordt gemaakt een minimum 1 tweede wachtperiode omvat. Deze wachttijd biedt de mogelijkheid om dit mechanisme te wijzigen en een geldige zakelijke reactie te verkrijgen.

Scenario-voorbeeld voor vertragen