(Veraltete) Fehlerberichte
- Themen:
- Authentifizierung
NOTE
IMPORTANTÜbersicht
Die Fehlerberichterstattung in der Adobe Pass-Authentifizierung wird derzeit auf zwei verschiedene Arten implementiert:
-
Erweiterte: Das Implementierungsprogramm registriert einen Fehler-Callback im Fall des AccessEnabler JavaScript SDK oder implementiert eine Schnittstellenmethode namens "
status" im Fall des AccessEnabler iOS/tvOS SDK und AccessEnabler Android SDK, um erweiterte Fehlerberichte zu erhalten. Fehler werden in die Typen Information, Warnung und Fehler kategorisiert. Dieses Berichtssystem ist asynchron da es keine Garantie für die Reihenfolge gibt, in der mehrere Fehler ausgelöst werden. Weitere Informationen zum erweiterten Fehlerberichterstattungssystem finden Sie im Abschnitt Erweiterte). -
Original Error Reporting - Ein statisches Berichtssystem, in dem Fehlermeldungen an bestimmte Callback-Funktionen übergeben werden, wenn bestimmte Anfragen fehlschlagen. Fehler werden in generische, Authentifizierungs- und Autorisierungstypen unterteilt. Eine Liste der im Originalsystem gemeldeten Fehler finden Sie im Abschnitt Original-).
Erweiterte Fehlerberichterstattung
IMPORTANTAccessEnabler JavaScript SDK
Das neue System zur Fehlerberichterstattung bleibt optional. Daher kann das Implementierungsprogramm einen Fehler-Handler-Callback explizit registrieren, um erweiterte Fehlerberichte zu erhalten. Das System bietet die Möglichkeit, mehrere Fehler-Callbacks dynamisch zu registrieren und ihre Registrierung aufzuheben. Darüber hinaus können Sie alle neuen Fehler-Callbacks registrieren, sobald die AccessEnabler JavaScript SDK geladen ist, ohne dass eine andere Initialisierung durchgeführt werden muss (vor dem Aufruf von setRequestor()), was bedeutet, dass Sie erweiterte Berichte über Initialisierungs- und Konfigurationsfehler erhalten können.
Implementierung
yourErrorHandler(errorData:Object)
Ihre Fehler-Handler-Rückruffunktion 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(eventType:String, handlerName:String):void
Fügt einen Handler für ein Ereignis an.
eventType - NUR der Wert "errorEvent" führt dazu, dass die 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]. Das heißt, Parameter müssen 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 Handlern für Bindungsfehler:
accessEnabler.bind('errorEvent', 'myCustomErrorHandler');
accessEnabler.bind('errorEvent', 'errorLogger');
Aufgrund technischer Einschränkungen ist es nicht möglich, einen Verschluss oder eine anonyme Funktion zu binden. Sie müssen den Namen der Methode im zweiten Parameter angeben.
2. Bindung aufheben
.unbind(eventType:String, handlerName:String=null):void
Entfernt einen zuvor angehängten Ereignishandler.
eventType - NUR der Wert "errorEvent" führt dazu, dass die AccessEnabler JavaScript SDK erweiterte Rückrufe von Fehlerberichten 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 fehlen, wird entfernt.
Beide Bindungsparameter dürfen nur Zeichen aus dem folgenden Satz verwenden: [0-9a-zA-Z][-._a-zA-Z0-9]. Das heißt, Parameter müssen 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 Fehler-Handler:
accessEnabler.unbind('errorEvent');
AccessEnabler iOS/tvOS SDK
Das neue Fehlermeldesystem ist obligatorisch, daher muss der Implementierer sich explizit an das neue Ziel-C-Protokoll „EntitlementStatus“ halten. Dieser neue Ansatz ermöglicht es Programmierern, erweiterte Fehlerberichte zu erhalten.
Implementierung
Eine Implementierung muss dem folgenden ""- entsprechen:
EntitlementStatus.h
#import <Foundation/Foundation.h>
@protocol EntitlementStatus <NSObject>
- (void)status:(NSDictionary *)statusDictionary;
@end
Ihre status-Funktion erhält ein einzelnes Objekt (einen NSDictionary) mit der folgenden Struktur:
{
errorId: "CFG410",
level: "error",
message: "This a fancy message", // Optional
.
. // Optional key/value pairs
.
}
1. Deklaration
@interface MyEntitlementStatusDelegate : NSObject <EntitlementStatus>
2. Implementierung
@implementation DemoAppAppDelegate
// very simple implementation
- (void)status:(NSDictionary *)statusDict {
NSLog(@"%@:\n%@", statusDict[@"level"], statusDict);
}
AccessEnabler Android SDK
Das neue Fehlerberichtssystem ist obligatorisch, da der Implementor explizit dem IAccessEnablerDelegate Schnittstellenprotokoll entsprechen muss. Dieser neue Ansatz ermöglicht es Programmierern, erweiterte Fehlerberichte zu erhalten.
Implementierung
Ein Implementor muss die neue status-Methode von der -Schnittstelle aus IAccessEnablerDelegate. Die status erhält ein einzelnes AdvancedStatus 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
Das neue Fehlerberichtssystem ist obligatorisch, da der Implementor explizit dem IAccessEnablerDelegate Schnittstellenprotokoll entsprechen muss. Dieser neue Ansatz ermöglicht es Programmierern, erweiterte Fehlerberichte zu erhalten.
Implementierung
Ein Implementor muss die neue Methode statusvon der -SchnittstelleIAccessEnablerDelegate verarbeiten. Die status erhält ein einzelnes AdvancedStatus 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 Fehler-Codes
In der folgenden Tabelle sind die Fehler-Codes der neueren Fehler-API aufgeführt und beschrieben, zusammen mit empfohlenen Maßnahmen zu ihrer Korrektur:
Weisen Sie den Benutzer an, sich explizit von „Einstellungen“ > „TV-Anbieter“ unter iOS/iPadOS abzumelden.
Melden Sie sich unter „Einstellungen“ > „TV-Anbieter“ unter iOS/iPadOS explizit ab.
- Adobe kontaktieren, um die Domain-Zulassungsliste für die
verwendete Anforderer-ID zu verwalten
- iOS: Vergewissern Sie sich, dass Sie das richtige Zertifikat verwenden und dass die Signatur ordnungsgemäß erstellt wurde
- Optional informieren Sie den Benutzer, dass er sich erneut anmelden muss.
[https://]{SP_FQDN\} im Browser und akzeptieren Sie die SSL-Zertifikate manuell, z. B. https://api.auth.adobe.com oder https://api.auth-staging.adobe.com- Markieren Sie die Proxy-Zertifikate als vertrauenswürdig
ergreifen Maßnahmen, um Flüsse von Ansprüchen zu verhindern, da diese wahrscheinlich fehlschlagen werden.
- Der Entwickler verfügt über ein ungültiges Spoofing.
: Der/die Benutzende hat Netzwerkprobleme und kann die Adobe Pass-Authentifizierungs-Domains nicht erreichen.
-Adobe Pass-Authentifizierungsserver sind falsch konfiguriert.
Hinweis: In Firefox wird CFG400 anstelle von CFG404 angezeigt (Browser-Einschränkung)
- Prüfen Sie die Netzwerk-/DNS-Einstellungen.
-Inform Adobe.
- Adobe Pass-Authentifizierung umgehen.
- Adobe informieren.
: Optional eine Liste der regulären MVPDs.
- Präsentieren Sie eine Liste der regulären MVPDs.
- Blendet die Option TempPass aus.
1. Im Browser sind Cookies von (Drittanbietern) deaktiviert (gilt nicht für AccessEnabler JavaScript SDK Version 4.x)
2. Browser hat Prevent cross-site tracking aktiviert (Safari 11+)
3. Sitzung ist
abgelaufen
4. Programmierer ruft Authentifizierungs-APIs in falscher
auf
HINWEIS: Dieser Fehler-Code ist nicht für Flüsse der vollständigen Umleitungs-Authentifizierung verfügbar.
2. Benutzer auffordern, Site-übergreifende Tracking-
zu deaktivieren
3. Benutzer auffordern, sich erneut zu authentifizieren
4. Aufrufen von APIs in der richtigen Reihenfolge
2. Site-übergreifendes Tracking
deaktivieren
3.
erneut authentifizieren
4. Nicht zutreffend
Hinweis: Dies ist der „Generische Authentifizierungsfehler“ und „Interner Authentifizierungsfehler“ des ursprünglichen Fehlersystems. Dieser Fehler wird schließlich schrittweise behoben.
Hinweis: Dies ist ein nicht behebbarer Fehler. Informieren Sie den Benutzer, dass die Anwendung nicht verfügbar ist.
- JavaScript: Überprüfen Sie die Software-Anweisung in Ihrer Website-Anwendung.
Öffnen Sie ein Ticket mit Zendesk und informieren Sie den Benutzer, dass das System vorübergehend nicht verfügbar ist
Hinweis: Dies ist ein nicht behebbarer Fehler. Informieren Sie den Benutzer, dass die Anwendung nicht verfügbar ist.
- JavaScript: Überprüfen Sie die Software-Anweisung in Ihrer Website-Anwendung.
Öffnen Sie ein Ticket mit Zendesk und informieren Sie den Benutzer, dass das System vorübergehend nicht verfügbar ist
Hinweis: Dies ist ein nicht behebbarer Fehler. Informieren Sie den Benutzer, dass die Anwendung nicht verfügbar ist.
- Informieren Sie den Benutzer.
- Der Schlüssel 'message' in der Fehlermeldung kann eine detailliertere Meldung enthalten, die von der MVPD bereitgestellt wird.
- Informieren Sie den Benutzer.
: Informieren Sie den Benutzer, dass beim MVPD Probleme aufgetreten sind, und versuchen Sie es später erneut.
Hinweis: Dies ist der alte „Generischer Authentifizierungsfehler“ und „Interner Authentifizierungsfehler“. Dieser Fehler wird schließlich schrittweise behoben.
- Wenden Sie sich an den Adobe Pass-Authentifizierungs-Support, um die maximal zulässige Anzahl von Ressourcen zu finden bzw. einzurichten.
Authentifizierung/Autorisierung bleibt nicht über die aktuelle Seite hinaus bestehen! Bei jedem Laden der Seite muss sich der Benutzer authentifizieren. Konfigurierte TTLs werden nicht über Seitenneuladungen hinweg erzwungen.
: Informieren Sie den Benutzer darüber, wie der verfügbare Speicherplatz erhöht werden kann.
- Alternativ können Sie sich abmelden, um den Speicher zu löschen.
- Melden Sie sich ab, um den Speicher zu leeren.
Ursprüngliche Fehlerberichterstattung
In diesem Abschnitt werden das ursprüngliche Fehlermeldesystem sowie die ursprünglichen Fehlercodes beschrieben. Im ursprünglichen Fehlermeldesystem übergibt AccessEnabler Fehler an diese beiden Callback-Funktionen: setAuthenticationStatus() nach einem Aufruf an checkAuthentication(); tokenRequestFailed() nach dem Ausfall eines Aufrufs an checkAuthorization() oder getAuthorization().
Die ursprünglichen Fehler-Reporting- und Status-APIs funktionieren weiterhin genau wie zuvor. Künftig werden die ursprünglichen Fehler-Reporting-APIs jedoch nicht mehr aktualisiert. Alle neuen Fehlermeldungen und Aktualisierungen zu den alten Fehlern werden NUR im neuen Advanced Error Reporting System“.
Beispiele für die Verwendung des ursprünglichen Fehlerberichtssystems finden Sie in den Funktionen JavaScript-API-Referenz:setAuthenticationStatus() und tokenRequestFailed(), iOS/tvOS-API-Referenz: setAuthenticationStatus()and tokentRequestFailed(), Android-API-Referenz: setAuthenticationStatus() und tokenRequestFailed().