Instructions relatives aux nouvelles tentatives pour ACS

  • Article

Mise à jour : 6 juillet 2015

S’applique à : Azure

Microsoft Azure Active Directory Access Control (également appelé service Access Control ou ACS) prend en charge un certain nombre de points de terminaison d’émission et de gestion de jetons différents auxquels les clients peuvent envoyer des demandes de jetons. Cette rubrique fournit des instructions pour l'implémentation d'une logique de nouvelle tentative en cas d'échec de demande de jetons.

Scénarios de gestion des erreurs

Les échecs de demande de jetons qui retournent des codes d'erreur de série HTTP 500 répondent généralement aux nouvelles tentatives. Dans certains scénarios, le client est une application ou un service qui effectue des requêtes automatisées auprès d’ACS. Dans d'autres scénarios, tels que la fédération web qui utilise le protocole WS-Federation, le client est un navigateur web et l'utilisateur final doit effectuer une nouvelle tentative manuellement. Cette rubrique traite de scénarios de gestion des erreurs dans lesquels le client est une application ou un service.

Ces scénarios sont les suivants :

Instructions relatives aux nouvelles tentatives

Les instructions suivantes expliquent comment implémenter une logique de nouvelle tentative dans les scénarios de gestion des erreurs.

Directive #1 : Implémenter une logique de nouvelle tentative en fonction des réponses d’erreur de la série HTTP 500

La logique de nouvelle tentative est fortement recommandée lorsque ACS retourne des erreurs de série HTTP 500. La liste suivante comprend des exemples d'erreurs de la série HTTP 500.

  • Erreur HTTP 500 - Erreur interne du serveur

  • Erreur HTTP 502 - Passerelle incorrecte

  • Erreur HTTP 503 - Service non disponible

  • Erreur HTTP 504 - Expiration du délai pour la passerelle

Bien que chaque code HTTP puisse être énuméré dans la logique de nouvelle tentative, il suffit d'appeler la logique de nouvelle tentative si une erreur de la série HTTP 500 est retournée.

La logique de nouvelle tentative doit être déclenchée par des codes d’erreur HTTP, tels que HTTP 504 (délai d’expiration du serveur externe), et non par des codes d’erreur ACS, tels que ACS90005. Les codes d’erreur ACS sont des codes informatifs et peuvent être modifiés.

En règle générale, la logique de nouvelle tentative n’est pas recommandée lorsque des codes d’erreur de série HTTP 400 sont retournés. Un code de réponse d’erreur de série HTTP 400 provenant du service ACS signifie que la demande n’est pas valide et doit être revue. Le code d'erreur 429 (« Trop de demandes ») est une exception : il indique que l'espace de noms a dépassé la limite du nombre de demandes de jetons pendant une période prolongée. Pour les erreurs 429, les nouvelles tentatives avec un minuteur d'interruption peuvent résoudre le backlog de demandes de jetons immédiat jusqu'à ce que l'administrateur ait le temps d'examiner et de corriger la distribution des charges de travail de l'espace de noms. Pour plus d’informations, consultez Limitations du service ACS.

Directive #2 : Les nouvelles tentatives doivent utiliser un minuteur de réinitialisation pour un contrôle de flux optimal

Quand un client reçoit une erreur de la série HTTP 500, il doit patienter pendant un laps de temps spécifié avant d'effectuer une nouvelle tentative. Pour de meilleurs résultats, il est recommandé de prolonger cette période à chaque nouvelle tentative. Cette approche permet de résoudre rapidement les erreurs temporaires tout en optimisant le taux de demandes pour les problèmes de réseau ou de serveur temporaires dont la résolution est plus longue.

Par exemple, utilisez un minuteur d’interruption exponentiel qui augmente le délai avant chaque nouvelle tentative de façon exponentielle, par exemple : 1 seconde pour la nouvelle tentative 1, 2 secondes pour la nouvelle tentative 2, 4 secondes pour la nouvelle tentative 3 et ainsi de suite.

Ajustez le nombre de nouvelles tentatives et le délai entre chacune d’elles en fonction de vos exigences en termes d’expérience utilisateur. Toutefois, nous recommandons jusqu’à cinq nouvelles tentatives sur une période de cinq minutes. Les échecs causés par le dépassement de délai sont plus longs à résoudre.

Directive #3 : Vérifiez que l’élément n’existe pas avant de tenter de créer ou de supprimer l’élément

Lors de la création ou de la suppression d’opérations avec le service de gestion ACS, comme la création d’une application de partie de confiance ou la suppression d’une règle, la logique de nouvelle tentative doit interroger si l’élément existe avant d’effectuer l’opération. Dans certaines circonstances, comme une défaillance réseau temporaire qui se produit lors de la remise de la réponse du serveur, une opération de création ou de suppression peut réussir même lorsque le client obtient une réponse d’erreur.

Si vous effectuez une nouvelle tentative d'opération de création sans vérifier l'existence de l'élément, vous risquez de créer des doublons. De plus, le système peut renvoyer une erreur HTTP 400 si l'élément doit être unique.

Si vous effectuez une nouvelle tentative d'opération de suppression sans vérifier l'existence de l'élément, le système risque de retourner une erreur HTTP 400 quand il ne trouve pas l'élément.

Voir aussi

Concepts

Codes d'erreur ACS
Limitations du service ACS
Service de gestion ACS
Demande de jeton à ACS via le protocole OAuth WRAP
Exemple de code : Authentification par certificat OAuth 2.0
Index des recommandations sur ACS