Richtlijnen voor opnieuw proberen van ACS
Bijgewerkt: 6 juli 2015
Van toepassing op: Azure
Microsoft Azure Active Directory Access Control (ook wel Access Control Service of ACS genoemd) ondersteunt een aantal verschillende tokenuitgifte- en beheereindpunten waarnaar clients tokenaanvragen kunnen verzenden. In dit onderwerp worden richtlijnen gedefinieerd voor het implementeren van logica voor opnieuw proberen wanneer tokenaanvragen mislukken.
Error-Handling-scenario's
Tokenaanvraagfouten die HTTP 500-serie foutcodes retourneren, reageren doorgaans op nieuwe pogingen. In sommige scenario's is de client een toepassing of service die geautomatiseerde aanvragen naar ACS verzendt. In andere scenario's, zoals webfederatie die gebruikmaakt van het protocol WS-Federation, is de client een webbrowser en moet de eindgebruiker de bewerking handmatig opnieuw proberen. In dit onderwerp worden scenario's voor foutafhandeling behandeld waarin de client een toepassing of service is.
Deze scenario's omvatten:
Beheerbewerkingen die gebruikmaken van de ACS Management Service
Tokenaanvragen voor webservices met behulp van het OAuth WRAP-protocol (zie Procedure: Een token aanvragen bij ACS via het OAuth WRAP-protocol)
Tokenaanvragen voor webservices met behulp van het OAuth 2.0-protocol (zie Codevoorbeeld: OAuth 2.0-certificaatverificatie)
Richtlijnen voor opnieuw proberen
In de volgende richtlijnen wordt uitgelegd hoe u logica voor opnieuw proberen implementeert in de scenario's voor foutafhandeling.
Richtlijn 1: Logica voor opnieuw proberen implementeren op basis van HTTP 500-serie foutreacties
Logica voor opnieuw proberen wordt sterk aanbevolen wanneer ACS HTTP 500-serie fouten retourneert. De volgende lijst bevat voorbeelden van typische HTTP 500-seriefouten.
HTTP-fout 500 - Interne serverfout
HTTP-fout 502 - Ongeldige gateway
HTTP-fout 503 - Service niet beschikbaar
HTTP-fout 504 – Time-out van gateway
Hoewel afzonderlijke HTTP-codes kunnen worden opgesomd in de logica voor opnieuw proberen, is het voldoende om logica voor opnieuw proberen aan te roepen als er een HTTP 500-reeksfout wordt geretourneerd.
Logica voor opnieuw proberen moet worden geactiveerd door HTTP-foutcodes, zoals HTTP 504 (time-out van externe server) en niet door ACS-foutcodes, zoals ACS90005. ACS-foutcodes zijn informatief en kunnen worden gewijzigd.
Normaal gesproken wordt logica voor opnieuw proberen niet aanbevolen wanneer foutcodes uit de HTTP 400-serie worden geretourneerd. Een HTTP-foutcode uit de 400-serie van ACS betekent dat de aanvraag ongeldig is en moet worden herzien. Eén uitzondering is foutcode 429 ("Te veel aanvragen"), waarmee wordt aangegeven dat de naamruimte de limiet voor de tokenaanvraagsnelheid voor een langere periode heeft overschreden. Bij 429-fouten kunnen nieuwe pogingen met een timer voor back-offs de achterstand van de tokenaanvraag oplossen totdat de beheerder tijd heeft om de workloaddistributie van de naamruimte te controleren en te herzien. Zie ACS-servicebeperkingen voor meer informatie.
Richtlijn 2: Nieuwe pogingen moeten een back-off timer gebruiken voor optimaal stroombeheer
Wanneer een client een HTTP 500-seriefout ontvangt, moet de client wachten op een opgegeven periode voordat de aanvraag opnieuw wordt uitgevoerd. Voor de beste resultaten wordt aanbevolen dat deze periode toeneemt met elke volgende nieuwe poging. Met deze methode kunnen tijdelijke fouten snel worden opgelost terwijl de aanvraagsnelheid wordt geoptimaliseerd voor tijdelijke netwerk- of serverproblemen die langer duren om op te lossen.
Gebruik bijvoorbeeld een timer voor exponentieel uitstel waarbij de vertraging voordat het opnieuw proberen exponentieel toeneemt met elk exemplaar, zoals Opnieuw proberen 1: 1 seconde, Opnieuw proberen 2: 2 seconden, Opnieuw proberen 3: 4 seconden, enzovoort.
Pas het aantal nieuwe pogingen en de tijd tussen elke nieuwe poging aan op basis van de vereisten voor uw gebruikerservaring. U wordt echter aangeraden maximaal vijf nieuwe pogingen uit te proberen gedurende een periode van vijf minuten. Fouten die worden veroorzaakt door een time-out, duren langer om op te lossen.
Richtlijn 3: Controleer of het item niet bestaat voordat u het probeert te maken of verwijderen
Wanneer u bewerkingen maakt of verwijdert met de ACS Management Service, zoals het maken van een nieuwe relying party-toepassing of het verwijderen van een regel, moet de logica voor opnieuw proberen een query uitvoeren als het item bestaat voordat de bewerking wordt uitgevoerd. In sommige gevallen, zoals een tijdelijke netwerkfout die optreedt tijdens het leveren van het serverantwoord, kan een bewerking voor het maken of verwijderen lukken, zelfs wanneer de client een foutreactie krijgt.
Als een bewerking voor het maken opnieuw wordt geprobeerd zonder te controleren of het item bestaat, kunnen er dubbele items worden gemaakt. , het systeem kan ook een HTTP 400-fout retourneren als het item uniek moet zijn.
Als een verwijderbewerking opnieuw wordt geprobeerd zonder te controleren op het bestaan van het item, kan het systeem een HTTP 400-fout retourneren wanneer het item niet kan worden gevonden.
Zie ook
Concepten
ACS-foutcodes
Beperkingen voor ACS-service
ACS Management-service
Procedure: Een token aanvragen bij ACS via het OAuth WRAP-protocol
Codevoorbeeld: OAuth 2.0-certificaatverificatie
ACS-richtlijnenindex