Fehlerberichte error-reporting

Übersicht overview

Die Fehlerberichterstellung in der Adobe Pass-Authentifizierung ist derzeit auf zwei verschiedene Arten implementiert:

Fortschrittliche Fehlerberichte advanced-error-reporting

AccessEnabler JavaScript-SDK accessenabler-javascript-sdk

Das neue Fehlermeldesystem ist optional. Daher kann der Implementor einen Rückruf des Fehler-Handlers explizit registrieren, um erweiterte Fehlerberichte zu erhalten. Das System bietet die Möglichkeit, mehrere Fehler-Rückrufe dynamisch zu registrieren und zu deaktivieren. Darüber hinaus können Sie alle neuen Fehlerrückrufe registrieren, sobald das AccessEnabler JavaScript-SDK geladen wird, ohne dass eine andere Initialisierung erforderlich ist (vor dem Aufruf von setRequestor()), was bedeutet, dass Sie erweiterte Berichte zu Initialisierungs- und Konfigurationsfehlern erhalten können.

Implementierung access-enab-js-imp

yourErrorHandler(errorData:Object)

Ihre Rückruffunktion des Fehler-Handlers erhält ein einzelnes Objekt (eine Zuordnung) mit der folgenden Struktur:

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

1. Bindung bind

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

Hängt einen Handler für ein Ereignis an.

eventType - NUR "errorEvent" führt dazu, dass das AccessEnabler JavaScript-SDK erweiterte Fehlerberichte auslöst.

handlerName - eine Zeichenfolge, die den Namen der Fehler-Handler-Funktion angibt.

Beide Bindungsparameter dürfen nur Zeichen aus dem folgenden Satz verwenden: [0-9a-zA-Z][-._a-zA-Z0-9]Parameter müssen also mit einer Zahl oder einem Buchstaben beginnen und dürfen dann nur Bindestriche, Punkte, Unterstriche und alphanumerische Zeichen enthalten. Darüber hinaus dürfen Parameter 1024 Zeichen nicht überschreiten.

Beispiel von Binding-Fehler-Handlern:

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

Aufgrund technischer Einschränkungen können Schließungen oder anonyme Funktionen nicht gebunden werden. Sie müssen den Namen der Methode im zweiten Parameter angeben.

2. Bindung aufheben unbind

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

Entfernt einen zuvor angehängten Ereignishandler.

eventType - NUR "errorEvent' -Wert führt zum JavaScript-SDK AccessEnabler , das erweiterte Rückrufe in Fehlerberichte auslöst.

handlerName - eine Zeichenfolge, die den Namen der Fehler-Handler-Funktion angibt, wenn null ist oder alle angehängten Handler für die angegebene eventType entfernt.

Beide Bindungsparameter dürfen nur Zeichen aus dem folgenden Satz verwenden: [0-9a-zA-Z][-._a-zA-Z0-9]Parameter müssen also mit einer Zahl oder einem Buchstaben beginnen und dürfen dann nur Bindestriche, Punkte, Unterstriche und alphanumerische Zeichen enthalten. Darüber hinaus dürfen Parameter 1024 Zeichen nicht überschreiten.

Beispiel Entfernen eines einzelnen Fehler-Handlers:

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

Beispiel Entfernen aller Fehlerhandler:

accessEnabler.unbind('errorEvent');

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

Das neue Fehlermeldesystem ist obligatorisch, daher muss der Implementor explizit dem neuen Objective C-"EntitlementStatus"-Protokoll entsprechen. Dieser neue Ansatz ermöglicht es Programmierern, erweiterte Fehlerberichte zu erhalten.

Implementierung accessenab-ios-tvossdk-imp

Ein Implementor muss Folgendes erfüllen: EntitlementStatus Protokoll:

EntitlementStatus.h

    #import <Foundation/Foundation.h>

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

Ihre status -Funktion erhält ein einzelnes Objekt (ein NSDictionary) mit der folgenden Struktur:

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

1. Erklärung

    @interface MyEntitlementStatusDelegate : NSObject <EntitlementStatus>

2. Implementierung

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

AccessEnabler Android SDK accessenabler-android-sdk

Das neue Fehlermeldesystem ist obligatorisch, da der Implementor explizit der Variablen IAccessEnablerDelegate Schnittstellendefiniertes Protokoll. Dieser neue Ansatz ermöglicht es Programmierern, erweiterte Fehlerberichte zu erhalten.

Implementierung access-enablr-androidsdk-imp

Ein Implementor muss die neue status -Methode über die -SchnittstelleIAccessEnablerDelegate. Die status -Funktion erhält eine einzige AdvancedStatus -Objekt mit dem folgenden Modell:

    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
    }

Beispiel

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

        Log.i(LOG_TAG, status);
    }

AccessEnabler FireOS-SDK accessenabler-fireos-sdk

Das neue Fehlermeldesystem ist obligatorisch, da der Implementor explizit der Variablen IAccessEnablerDelegate Schnittstellendefiniertes Protokoll. Dieser neue Ansatz ermöglicht es Programmierern, erweiterte Fehlerberichte zu erhalten.

Implementierung access-enab-fireos-sdk-

Ein Implementor muss die neue status-Methode über die -SchnittstelleIAccessEnablerDelegate. Die status -Funktion erhält eine einzige AdvancedStatus -Objekt mit dem folgenden Modell:

    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
    }

Beispiel

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

        Log.i(LOG_TAG, status);
    }

Referenz zu erweiterten Fehlercodes advanced-error-codes-reference

In der folgenden Tabelle sind die von der neueren Fehler-API offen gelegten Fehler-Codes sowie die zu ihrer Korrektur empfohlenen Maßnahmen aufgeführt und beschrieben:

Ursprüngliche Fehlerberichte original-error-reporting

In diesem Abschnitt wird das ursprüngliche Fehlermeldesystem zusammen mit den ursprünglichen Fehlercodes beschrieben. Im ursprünglichen Fehlermeldesystem übergibt der AccessEnabler Fehler an diese beiden Callback-Funktionen: setAuthenticationStatus() nach einem Aufruf von checkAuthentication(); tokenRequestFailed(), nachdem ein -Aufruf an checkAuthorization() oder getAuthorization().

Die ursprünglichen Fehler-Berichte und Status-APIs funktionieren weiterhin genau wie zuvor. Die ursprünglichen Fehler-Reporting-APIs werden jedoch in Zukunft nicht aktualisiert. Alle neuen Fehlerberichte und Aktualisierungen zu den alten Fehlern werden NUR in der neuen Erweitertes Fehlermeldungssystem.

Beispiele für die Verwendung des ursprünglichen Fehlermeldesystems finden Sie unter JavaScript-API-Referenz:setAuthenticationStatus() und tokenRequestFailed() Funktionen, iOS/tvOS-API-Referenz: setAuthenticationStatus()und tokentRequestFailed(), Android-API-Referenz: setAuthenticationStatus() und tokenRequestFailed().

Ursprüngliche Rückruffehlercodes original-callback-error-codes