Megosztás a következőn keresztül:

Az ACS újrapróbálkozési irányelvei

  • Cikk

Frissítve: 2015. július 6.

Érintett kiadások: Azure

Microsoft Azure Active Directory Access Control (más néven Access Control Szolgáltatás vagy ACS) számos különböző jogkivonat-kiállítási és felügyeleti végpontot támogat, amelyekre az ügyfelek jogkivonat-kérelmeket küldhetnek. Ez a témakör irányelveket határoz meg az újrapróbálkozási logika implementálásához a jogkivonat-kérelmek meghiúsulása esetén.

Error-Handling forgatókönyvek

A HTTP 500-as sorozatú hibakódokat visszaadó jogkivonatkérési hibák általában az újrapróbálkozásokra reagálnak. Bizonyos esetekben az ügyfél egy olyan alkalmazás vagy szolgáltatás, amely automatizált kéréseket küld az ACS-nek. Más esetekben, például a WS-Federation protokollt használó webalapú összevonás esetén az ügyfél egy webböngésző, és a végfelhasználónak manuálisan kell újrapróbálnia a műveletet. Ez a témakör azokat a hibakezelési forgatókönyveket ismerteti, amelyekben az ügyfél egy alkalmazás vagy szolgáltatás.

Ezek a forgatókönyvek a következőket biztosítják:

Újrapróbálkozési irányelvek

Az alábbi irányelvek bemutatják, hogyan valósíthat meg újrapróbálkozési logikát a hibakezelési forgatókönyvekben.

1. útmutató: Újrapróbálkozési logika implementálása HTTP 500-sorozatú hibaválaszok alapján

Az újrapróbálkozások logikája erősen ajánlott, ha az ACS HTTP 500-as sorozatú hibákat ad vissza. Az alábbi lista példákat tartalmaz a tipikus 500-as sorozatú HTTP-hibákra.

  • 500-os HTTP-hiba – Belső kiszolgálóhiba

  • 502-ös HTTP-hiba – Hibás átjáró

  • 503-os HTTP-hiba – A szolgáltatás nem érhető el

  • 504-as HTTP-hiba – Átjáró időtúllépése

Bár az egyes HTTP-kódok számba vehetők az újrapróbálkozási logikában, elegendő újrapróbálkozási logikát meghívni, ha http 500-as sorozatú hibát ad vissza.

Az újrapróbálkozások logikáját HTTP-hibakódok, például HTTP 504 (külső kiszolgáló időtúllépése) aktiválja, és nem az ACS-hibakódok, például az ACS90005. Az ACS-hibakódok tájékoztató jellegűek, és változhatnak.

Az újrapróbálkozás logikája általában nem ajánlott HTTP 400-as sorozatú hibakódok visszaadásakor. Az ACS 400-as sorozatú HTTP-hibaválaszkódja azt jelenti, hogy a kérés érvénytelen, és módosítani kell. Az egyik kivétel a 429-s hibakód ("Túl sok kérelem"), amely azt jelzi, hogy a névtér hosszabb ideje túllépte a jogkivonat-kérelmek sebességkorlátját. 429-re vonatkozó hibák esetén a visszatartási időzítővel történő újrapróbálkozások megoldhatják az azonnali jogkivonat-kérelmek hátralékát, amíg a rendszergazdának nincs ideje a névtér számítási feladatainak elosztásának áttekintésére és felülvizsgálatára. További információ: Az ACS szolgáltatás korlátozásai.

2. útmutató: Az újrapróbálkozásoknak visszakapcsolási időzítőt kell használniuk az optimális folyamatvezérléshez

Amikor egy ügyfél HTTP 500-as sorozatú hibát kap, az ügyfélnek meg kell várnia egy megadott ideig, mielőtt újrapróbálkozik a kéréssel. A legjobb eredmény érdekében javasoljuk, hogy ezt az időtartamot minden további újrapróbálkozással növelje. Ez a megközelítés lehetővé teszi az átmeneti hibák gyors megoldását, miközben optimalizálja a kérelmek arányát az átmeneti hálózati vagy kiszolgálói problémák megoldásához, amelyek megoldása hosszabb időt vesz igénybe.

Használjon például exponenciális visszatartási időzítőt, amelyben az újrapróbálkozás előtti késleltetés exponenciálisan nő minden egyes példánnyal, például: 1. újrapróbálkozás: 1 másodperc, újrapróbálkozás 2: 2 másodperc, újrapróbálkozás 3: 4 másodperc stb.

Az újrapróbálkozések számát és az egyes újrapróbálkozások közötti időt a felhasználói élmény követelményei alapján módosíthatja. Javasoljuk azonban, hogy öt perc alatt legfeljebb öt újrapróbálkozás legyen. Az időtúllépés által okozott hibák megoldása hosszabb időt vesz igénybe.

3. útmutató: Az elem létrehozásának vagy törlésének megkísérlése előtt ellenőrizze, hogy az elem nem létezik-e

Amikor létrehozási vagy törlési műveleteket hajt végre az ACS felügyeleti szolgáltatással, például új függő entitásalkalmazást hoz létre vagy töröl egy szabályt, az újrapróbálkozási logikának le kell kérdeznie, hogy az elem létezik-e a művelet végrehajtása előtt. Bizonyos esetekben , például egy átmeneti hálózati hiba, amely a kiszolgáló válaszának kézbesítése közben következik be, a létrehozási vagy törlési művelet akkor is sikeres lehet, ha az ügyfél hibaüzenetet kap.

Ha a rendszer az elem meglétének ellenőrzése nélkül újrapróbálkozott egy létrehozási művelettel, ismétlődő elemek hozhatók létre. , Emellett a rendszer HTTP 400-ra vonatkozó hibát is visszaadhat, ha az elemnek egyedinek kell lennie.

Ha egy törlési műveletet az elem meglétének ellenőrzése nélkül próbál meg újra végrehajtani, előfordulhat, hogy a rendszer HTTP 400-os hibát ad vissza, ha nem találja az elemet.

Lásd még:

Alapelvek

ACS-hibakódok
Az ACS szolgáltatás korlátozásai
ACS felügyeleti szolgáltatás
Útmutató: Jogkivonat kérése az ACS-től az OAuth WRAP protokollon keresztül
Kódminta: OAuth 2.0-tanúsítványhitelesítés
ACS-irányelvek indexe