Dela via

Riktlinjer för återförsök i ACS

  • Artikel

Uppdaterad: 6 juli 2015

Gäller för: Azure

Microsoft Azure Active Directory Access Control (kallas även Access Control Service eller ACS) stöder ett antal olika tokenutfärdnings- och hanteringsslutpunkter som klienter kan skicka tokenbegäranden till. Det här avsnittet definierar riktlinjer för att implementera logik för omförsök när tokenbegäranden misslyckas.

Error-Handling scenarier

Fel vid tokenbegäran som returnerar felkoder i HTTP 500-serien svarar vanligtvis på återförsök. I vissa fall är klienten ett program eller en tjänst som gör automatiserade begäranden till ACS. I andra scenarier, till exempel webbaserad federation som använder WS-Federation-protokollet, är klienten en webbläsare och slutanvändaren måste försöka utföra åtgärden manuellt igen. Det här avsnittet beskriver felhanteringsscenarier där klienten är ett program eller en tjänst.

Några vanliga scenarier:

Riktlinjer för återförsök

Följande riktlinjer beskriver hur du implementerar omprövningslogik i felhanteringsscenarierna.

Riktlinje nr 1: Implementera omprövningslogik baserat på HTTP 500-seriens felsvar

Omprövningslogik rekommenderas starkt när ACS returnerar HTTP 500-seriefel. Följande lista innehåller exempel på vanliga HTTP 500-seriefel.

  • HTTP-fel 500 – internt serverfel

  • HTTP-fel 502 – Felaktig gateway

  • HTTP-fel 503 – Tjänsten är inte tillgänglig

  • HTTP-fel 504 – Gateway-timeout

Även om enskilda HTTP-koder kan räknas upp i omprövningslogik räcker det att anropa logik för återförsök om ett HTTP 500-seriefel returneras.

Logik för återförsök ska utlösas av HTTP-felkoder, till exempel HTTP 504 (tidsgräns för extern server) och inte av ACS-felkoder, till exempel ACS90005. ACS-felkoder är informationsbaserade och kan komma att ändras.

Normalt rekommenderas inte omprövningslogik när felkoder i HTTP 400-serien returneras. En HTTP-felsvarskod i 400-serien från ACS innebär att begäran är ogiltig och måste revideras. Ett undantag är felkoden 429 ("För många begäranden") som anger att namnområdet har överskridit gränsen för tokenbegärandefrekvens under en längre period. Vid 429-fel kan återförsök med en backoff-timer lösa kvarvarande uppgifter för begäran om omedelbar token tills administratören har tid att granska och ändra arbetsbelastningsdistributionen för namnområdet. Mer information finns i BEGRÄNSNINGAR för ACS-tjänsten.

Riktlinje nr 2: Återförsök bör använda en timer för backoff för optimal flödeskontroll

När en klient får ett HTTP 500-seriefel bör klienten vänta en angiven tidsperiod innan begäran görs igen. För bästa resultat rekommenderar vi att den här tidsperioden ökar med varje efterföljande återförsök. Med den här metoden kan tillfälliga fel lösas snabbt samtidigt som begärandefrekvensen optimeras för tillfälliga nätverk eller serverproblem som tar längre tid att lösa.

Använd till exempel en exponentiell timer där fördröjningen innan återförsöket ökar exponentiellt med varje instans, till exempel Försök igen 1: 1 sekund, Försök igen 2: 2 sekunder, Försök igen 3: 4 sekunder och så vidare.

Justera antalet återförsök och tiden mellan varje återförsök baserat på kraven för användarupplevelsen. Vi rekommenderar dock upp till fem återförsök under en period på fem minuter. Det tar längre tid att lösa fel som orsakas av en tidsgräns.

Riktlinje nr 3: Kontrollera att objektet inte finns innan du försöker skapa eller ta bort det

När du utför åtgärder för att skapa eller ta bort med ACS-hanteringstjänsten, till exempel skapa ett nytt förlitande part-program eller ta bort en regel, ska omprövningslogik fråga om objektet finns innan åtgärden utförs. I vissa fall, till exempel ett tillfälligt nätverksfel som inträffar när serversvaret levereras, kan en skapande- eller borttagningsåtgärd lyckas även när klienten får ett felsvar.

Om ett nytt försök görs att skapa en åtgärd utan att kontrollera om objektet finns kan dubblettobjekt skapas. , Systemet kan också returnera ett HTTP 400-fel om objektet måste vara unikt.

Om ett borttagningsförsök görs igen utan att kontrollera om objektet finns kan systemet returnera ett HTTP 400-fel när det inte går att hitta objektet.

Se även

Begrepp

ACS-felkoder
Begränsningar för ACS-tjänsten
ACS-hanteringstjänst
Anvisningar: Begära en token från ACS via OAuth WRAP Protocol
Kodexempel: OAuth 2.0-certifikatautentisering
INDEX för ACS-riktlinjer