Rapport d’erreurs error-reporting

Vue d’ensemble overview

Le rapport d’erreurs dans l’authentification Adobe Pass est actuellement implémenté de deux manières différentes :

Rapport d’erreurs avancé advanced-error-reporting

SDK JavaScript AccessEnabler accessenabler-javascript-sdk

Le nouveau système de création de rapports d’erreurs est facultatif. Par conséquent, l’implémentateur peut enregistrer explicitement un rappel de gestionnaire d’erreurs pour recevoir des rapports d’erreur avancés. Le système offre la possibilité d’enregistrer et d’annuler l’enregistrement dynamique de plusieurs rappels d’erreur. En outre, vous pouvez enregistrer de nouveaux rappels d’erreur dès que le SDK JavaScript AccessEnabler est chargé, sans avoir à effectuer d’autre initialisation (avant d’appeler setRequestor()), ce qui signifie que vous avez la possibilité de recevoir des rapports avancés sur les erreurs d’initialisation et de configuration.

Implémentation access-enab-js-imp

yourErrorHandler(errorData:Object)

Votre fonction de rappel de gestionnaire d’erreurs recevra un seul objet (une carte) avec la structure suivante :

    {
      errorId: "CFG410",
      level: "error",
      message: "This a fancy message",  // Optional
      .
      .                                 // Optional key/value pairs
      .
    }

1. Liaison bind

.bind(eventType:String, handlerName:String):void

Joint un gestionnaire pour un événement.

eventType - SEULE la valeur "errorEvent" entraîne le déclenchement par le SDK JavaScript AccessEnabler de rappels avancés de rapports d’erreur.

handlerName : chaîne spécifiant le nom de la fonction du gestionnaire d’erreurs.

Les deux paramètres de liaison ne doivent utiliser que les caractères de l’ensemble suivant : [0-9a-zA-Z][-._a-zA-Z0-9]. En d’autres termes, les paramètres doivent commencer par un nombre ou une lettre, et ne peuvent alors inclure que des tirets, des points, des traits de soulignement et des caractères alphanumériques. En outre, les paramètres ne peuvent pas dépasser 1 024 caractères.

Exemple de gestionnaires d’erreurs de liaison :

accessEnabler.bind('errorEvent', 'myCustomErrorHandler');
accessEnabler.bind('errorEvent', 'errorLogger');

En raison de limitations techniques, vous ne pouvez pas lier une fermeture ou une fonction anonyme. Vous devez spécifier le nom de la méthode dans le deuxième paramètre.

2. Délier unbind

.unbind(eventType:String, handlerName:String=null):void

Supprime un gestionnaire d’événements précédemment joint.

eventType - SEULE la valeur 'errorEvent' entraîne le déclenchement du SDK JavaScript AccessEnabler qui déclenche des rappels avancés pour les rapports d’erreur.

handlerName - Une chaîne spécifiant le nom de la fonction du gestionnaire d’erreurs, si est nul ou si tous les gestionnaires associés sont manquants pour le eventType spécifié sera supprimé.

Les deux paramètres de liaison ne doivent utiliser que les caractères de l’ensemble suivant : [0-9a-zA-Z][-._a-zA-Z0-9]. En d’autres termes, les paramètres doivent commencer par un nombre ou une lettre, et ne peuvent alors inclure que des tirets, des points, des traits de soulignement et des caractères alphanumériques. En outre, les paramètres ne peuvent pas dépasser 1 024 caractères.

Exemple de suppression d’un gestionnaire d’erreurs unique :

accessEnabler.unbind('errorEvent', 'errorLogger');

Exemple supprimant tous les gestionnaires d’erreurs :

accessEnabler.unbind('errorEvent');

SDK AccessEnabler iOS/tvOS accessenabler-ios-tvos-sdk

Le nouveau système de reporting des erreurs est obligatoire. Par conséquent, l’implémentateur doit se conformer explicitement au nouveau protocole Objective C "EntitlementStatus". Cette nouvelle approche permet aux programmeurs de recevoir des rapports d’erreur avancés.

Implémentation accessenab-ios-tvossdk-imp

Un implémentateur doit se conformer au protocole EntitlementStatus suivant :

EntitlementStatus.h

    #import <Foundation/Foundation.h>

    @protocol EntitlementStatus <NSObject>
    - (void)status:(NSDictionary *)statusDictionary;
    @end

Votre fonction status recevra un seul objet (un NSDictionary) avec la structure suivante :

    {
          errorId: "CFG410",
          level: "error",
          message: "This a fancy message",  // Optional
      .
      .                                 // Optional key/value pairs
      .
    }

1. Déclaration

    @interface MyEntitlementStatusDelegate : NSObject <EntitlementStatus>

2. Implémentation

    @implementation DemoAppAppDelegate
    // very simple implementation
    - (void)status:(NSDictionary *)statusDict {
        NSLog(@"%@:\n%@", statusDict[@"level"], statusDict);
    }

SDK Android AccessEnabler accessenabler-android-sdk

Le nouveau système de création de rapports d’erreurs est obligatoire, car l’implémentateur doit explicitement se conformer au protocole défini par l’interface IAccessEnablerDelegate. Cette nouvelle approche permet aux programmeurs de recevoir des rapports d’erreur avancés.

Implémentation access-enablr-androidsdk-imp

Un implémentateur doit gérer la nouvelle méthode status à partir de l’interfaceIAccessEnablerDelegate. La fonction status recevra un seul objet AdvancedStatus avec le modèle suivant :

    class AdvancedStatus {

    String id; // Not Null
    String level; // Not Null
    String message; // Might be null
    String resource; // Might be null

    AdvancedStatus(String id, String level, String message, String resource) {
        this.id = id;
        this.level = level;
        this.message = message;
        this.resource = resource;
    }

    //other private/public methods
    }

Sample

    @Override
    public void status(AdvancedStatus advancedStatus) {
        String status = "status(" + advancedStatus.id + ", " + advancedStatus.level + ", " + advancedStatus.message + ", " + advancedStatus.resource + ")";

        Log.i(LOG_TAG, status);
    }

SDK AccessEnabler FireOS accessenabler-fireos-sdk

Le nouveau système de création de rapports d’erreurs est obligatoire, car l’implémentateur doit explicitement se conformer au protocole défini par l’interface IAccessEnablerDelegate. Cette nouvelle approche permet aux programmeurs de recevoir des rapports d’erreur avancés.

Implémentation access-enab-fireos-sdk-

Un implémentateur doit gérer la nouvelle méthode statusà partir de l’interfaceIAccessEnablerDelegate. La fonction status recevra un seul objet AdvancedStatus avec le modèle suivant :

    class AdvancedStatus {

    String id; // Not Null
    String level; // Not Null
    String message; // Might be null
    String resource; // Might be null

    AdvancedStatus(String id, String level, String message, String resource) {
        this.id = id;
        this.level = level;
        this.message = message;
        this.resource = resource;
    }

    //other private/public methods
    }

Sample

    @Override
    public void status(AdvancedStatus advancedStatus) {
        String status = "status(" + advancedStatus.id + ", " + advancedStatus.level + ", " + advancedStatus.message + ", " + advancedStatus.resource + ")";

        Log.i(LOG_TAG, status);
    }

Référence des codes d’erreur avancés advanced-error-codes-reference

Le tableau suivant répertorie et décrit les codes d’erreur exposés par la nouvelle API d’erreur, ainsi que les actions suggérées pour les corriger :

Rapport d’erreurs d’origine original-error-reporting

Cette section décrit le système de reporting des erreurs d’origine, ainsi que les codes d’erreur d’origine. Dans le système de création de rapports d’erreurs d’origine, AccessEnabler transmet les erreurs à ces deux fonctions de rappel : setAuthenticationStatus() après un appel à checkAuthentication() ; tokenRequestFailed(), après l’échec d’un appel à checkAuthorization() ou getAuthorization().

Les rapports d’erreur d’origine et les API d’état continuent de fonctionner exactement comme auparavant. Toutefois, à l’avenir, les API de création de rapports d’erreur d’origine ne seront pas mises à jour. Tous les nouveaux rapports d’erreur et mises à jour sur les anciennes erreurs seront UNIQUEMENT répercutés dans le nouveau système de création de rapports d’erreurs avancé.

Pour obtenir des exemples d’utilisation du système de reporting d’erreur d’origine, voir les fonctions Référence de l’API JavaScript:setAuthenticationStatus() et tokenRequestFailed(), Référence de l’API iOS/tvOS : setAuthenticationStatus()} et 🔗tokentRequestRequestFailed(){1RequestRequestRequestRequestRequest Référence de l’API Android : setAuthenticationStatus() et tokenRequestFailed().

Codes d’erreur de rappel d’origine original-callback-error-codes