iOS/tvOS-SDK-Cookbook iostvos-sdk-cookbook

Erstellen Sie Ihre Callback-Funktionen:

• setRequestorComplete()

• Ausgelöst von setRequestor(), gibt Erfolg oder Fehler zurück.

• "Erfolg"bedeutet, dass Sie mit Berechtigungsaufrufen fortfahren können.

• displayProviderDialog(mvpds)

  • Ausgelöst von getAuthentication() nur dann, wenn der Benutzer keinen Anbieter (MVPD) ausgewählt hat und noch nicht authentifiziert ist.
  • Die mvpds -Parameter ist ein Array von Anbietern, die dem Benutzer zur Verfügung stehen.

• setAuthenticationStatus(status, errorcode)

  • Ausgelöst von checkAuthentication() jedes Mal.
  • Ausgelöst von getAuthentication() nur dann, wenn der Benutzer bereits authentifiziert ist und einen Provider ausgewählt hat.
  • Status zurückgegeben ist erfolgreich oder fehlgeschlagen, der Fehlertyp wird im Fehlercode beschrieben.

• navigateToUrl(url)

  • Ausgelöst von getAuthentication() nachdem der Benutzer einen MVPD ausgewählt hat. Die url liefert den Speicherort der Anmeldeseite des MVPD.

• sendTrackingData(event, data)

  • Ausgelöst von checkAuthentication(), getAuthentication(), checkAuthorization(), getAuthorization(), setSelectedProvider().
  • Die event -Parameter gibt an, welches Berechtigungsereignis aufgetreten ist; der data -Parameter ist eine Liste von Werten, die sich auf das Ereignis beziehen.

• setToken(token, resource)

  • Ausgelöst von checkAuthorization() und getAuthorization() nach erfolgreicher Autorisierung zum Anzeigen einer Ressource.
  • Die token -Parameter ist das kurzlebige Medien-Token; die resource -Parameter ist der Inhalt, den der Benutzer anzeigen darf.

• tokenRequestFailed(resource, code, description)

  • Ausgelöst von checkAuthorization() und getAuthorization() nach einer nicht erfolgreichen Autorisierung.
  • Die resource -Parameter ist der Inhalt, den der Benutzer anzuzeigen versucht hat; die code -Parameter ist der Fehlercode, der angibt, welcher Fehlertyp aufgetreten ist; der description -Parameter beschreibt den Fehler, der dem Fehlercode zugeordnet ist.

• selectedProvider(mvpd)

  • Ausgelöst von getSelectedProvider().
  • Die mvpd liefert Informationen zum vom Benutzer ausgewählten Provider.

• setMetadataStatus(metadata, key, arguments)

  • Ausgelöst von getMetadata().
  • Die metadata liefert die spezifischen Daten, die Sie angefordert haben; die key -Parameter ist der Schlüssel, der in der Variablen getMetadata() und die arguments ist dasselbe Wörterbuch, das an getMetadata().

• preauthorizedResources(authorizedResources]

  • Ausgelöst von checkPreauthorizedResources().

  • Die authorizedResources -Parameter zeigt die Ressourcen an, die der Benutzer anzeigen darf.

• presentTvProviderDialog(viewController)

  • Ausgelöst von getAuthentication() wenn der aktuelle Anfragende mindestens MVPD unterstützt, das SSO-Unterstützung hat.
  • Der Parameter viewController ist das Apple SSO-Dialogfeld und muss auf dem Hauptansichtscontroller angezeigt werden.

• dismissTvProviderDialog(viewController)

  • Wird durch eine Benutzeraktion ausgelöst (durch die Auswahl von "Abbrechen"oder "Andere TV-Anbieter"im Dialogfeld "Apple SSO").
  • Der Parameter viewController ist das Apple SSO-Dialogfeld und muss vom Hauptansichtscontroller verworfen werden.

Starten Sie die Anwendung der obersten Ebene.

Adobe Pass-Authentifizierung initiieren

a. Aufruf init , um eine einzelne Instanz von Adobe Pass Authentication AccessEnabler zu erstellen.

• Abhängigkeit: Native iOS/tvOS-Bibliothek für Adobe Pass-Authentifizierung (AccessEnabler)

b. Aufruf setRequestor() die Identität des Programmierers festzustellen; requestorID und (optional) ein Array von Adobe Pass-Authentifizierungsendpunkten. Für tvOS müssen Sie auch den öffentlichen Schlüssel und das Geheimnis angeben. Siehe Clientlose Dokumentation für Details.

• Abhängigkeit: Gültige Adobe Pass Authentication RequestID (wenden Sie sich an Ihren Adobe Pass Authentication Account Manager, um dies anzuordnen).

• Trigger:

  setRequestorComplete() Callback.

Sie haben zwei Implementierungsoptionen: Sobald die Identifizierungsinformationen des Anfragenden an den Backend-Server gesendet wurden, kann die UI-Anwendungsschicht einen der beiden folgenden Ansätze wählen:

1. Warten Sie auf die Auslösung der setRequestorComplete() callback (Teil des AccessEnabler -Delegates). Diese Option bietet die größte Sicherheit, dass setRequestor() abgeschlossen ist, daher wird dies für die meisten Implementierungen empfohlen.

2. Fahren Sie fort, ohne auf die Aktivierung der setRequestorComplete() zurücksetzen und mit der Ausgabe von Berechtigungsanfragen beginnen. Diese Aufrufe (checkAuthentication, checkAuthorization, getAuthentication, getAuthorization, checkPreauthorizedResource, getMetadata, logout) werden von der AccessEnabler-Bibliothek in die Warteschlange gestellt, die die tatsächlichen Netzwerkaufrufe nach der setRequestor(). Diese Option kann gelegentlich unterbrochen werden, wenn beispielsweise die Netzwerkverbindung instabil ist.

Aufruf checkAuthentication() um nach einer vorhandenen Authentifizierung zu suchen, ohne den vollständigen Authentifizierungsfluss zu starten. Wenn dieser Aufruf erfolgreich ist, können Sie direkt zum Autorisierungsfluss übergehen. Ist dies nicht der Fall, fahren Sie mit dem Authentifizierungsfluss fort.

• Abhängigkeit: Ein erfolgreicher Aufruf an setRequestor() (Diese Abhängigkeit gilt auch für alle nachfolgenden Aufrufe).

• Trigger: setAuthenticationStatus() Callback.

Aufruf getAuthentication() , um den Authentifizierungsfluss zu initiieren oder um zu bestätigen, dass der Benutzer bereits authentifiziert ist.

Trigger:

• Die setAuthenticationStatus() Callback, wenn der Benutzer bereits authentifiziert ist. Gehen Sie in diesem Fall direkt zum Autorisierungsfluss.

• Die displayProviderDialog() Callback, wenn der Benutzer noch nicht authentifiziert ist.

Präsentieren Sie den Benutzer mit der Liste der Anbieter, die an gesendet werden
displayProviderDialog().

Nachdem der Benutzer einen Anbieter ausgewählt hat, rufen Sie die URL des MVPD des Benutzers aus der navigateToUrl: oder navigateToUrl:useSVC: Callback und Öffnen einer UIWebView/WKWebView oder SFSafariViewController und leitet diesen Controller zur URL weiter.

Durch die UIWebView/WKWebView oder SFSafariViewController im vorherigen Schritt instanziiert wurde, landet der Benutzer auf der Anmeldeseite des MVPD und gibt Anmeldedaten ein. Mehrere Umleitungsvorgänge finden innerhalb des Controllers statt.

Nach erfolgreicher Anmeldung durch den Benutzer erkennt Ihre Anwendungsebene das Laden einer bestimmten benutzerdefinierten URL. Beachten Sie, dass diese spezifische benutzerdefinierte URL tatsächlich ungültig ist und nicht für den Controller vorgesehen ist, sie tatsächlich zu laden. Sie darf nur von Ihrer Anwendung als Signal interpretiert werden, dass der Authentifizierungsvorgang abgeschlossen ist und dass das Schließen der UIWebView/WKWebView oder SFSafariViewController Controller. Im Fall von SFSafariViewControllerDer Controller muss verwendet werden, wenn die spezifische benutzerdefinierte URL von der application's custom scheme (z. B.adbe.u-XFXJeTSDuJiIQs0HVRAg://adobe.com). Andernfalls wird diese spezifische benutzerdefinierte URL durch die Variable ADOBEPASS_REDIRECT_URL Konstante (d. h. adobepass://ios.app).

Schließen Sie den Controller UIWebView/WKWebView oder SFSafariViewController und rufen Sie den handleExternalURL:url API-Methode, die den AccessEnabler anweist, das Authentifizierungstoken vom Backend-Server abzurufen.

(Optional) Aufruf checkPreauthorizedResources(resources) , um zu überprüfen, welche Ressourcen der Benutzer anzeigen darf. Die resources parameter ist ein Array geschützter Ressourcen, die mit dem Authentifizierungstoken des Benutzers verknüpft sind. Eine Verwendung der Autorisierungsinformationen, die vom MVPD des Benutzers erhalten werden, besteht darin, Ihre Benutzeroberfläche zu dekorieren (z. B. gesperrte/entsperrte Symbole neben geschützten Inhalten).

• Trigger: preauthorizedResources() callback
• Ausführungspunkt: Nach Abschluss des Authentifizierungsablaufs

Wenn die Authentifizierung erfolgreich war, fahren Sie mit dem Autorisierungsfluss fort.

Aufruf getAuthentication() , um den Authentifizierungsfluss zu initiieren oder um zu bestätigen, dass der Benutzer bereits authentifiziert ist.
Trigger:

• Die presentTvProviderDialog() Callback, wenn der Benutzer nicht authentifiziert ist und der aktuelle Anforderer mindestens über MVPD verfügt, der SSO unterstützt. Wenn keine MVPDs SSO unterstützen, wird der klassische Authentifizierungsfluss verwendet.

Nachdem der Benutzer einen Anbieter ausgewählt hat, ruft die AccessEnabler-Bibliothek ein Authentifizierungstoken mit den Informationen ab, die vom VSA-Framework von Apple bereitgestellt werden.

Die setAuthenticationsStatus() Callback wird ausgelöst. An dieser Stelle sollte der Benutzer bei Apple SSO authentifiziert werden.

[Optional] Aufruf checkPreauthorizedResources(resources) , um zu überprüfen, welche Ressourcen der Benutzer anzeigen darf. Die resources parameter ist ein Array geschützter Ressourcen, die mit dem Authentifizierungstoken des Benutzers verknüpft sind. Eine Verwendung der Autorisierungsinformationen, die vom MVPD des Benutzers erhalten werden, besteht darin, Ihre Benutzeroberfläche zu dekorieren (z. B. gesperrte/entsperrte Symbole neben geschützten Inhalten).

• Trigger: preauthorizedResources() callback
• Ausführungspunkt: Nach Abschluss des Authentifizierungsablaufs

Wenn die Authentifizierung erfolgreich war, fahren Sie mit dem Autorisierungsfluss fort.

Aufruf getAuthentication() , um den Authentifizierungsfluss zu initiieren oder um zu bestätigen, dass der Benutzer bereits authentifiziert ist.
Trigger:

• Die presentTvProviderDialog() Callback, wenn der Benutzer nicht authentifiziert ist und der aktuelle Anforderer mindestens über MVPD verfügt, der SSO unterstützt. Wenn keine MVPDs SSO unterstützen, wird der klassische Authentifizierungsfluss verwendet.

Nachdem der Benutzer einen Anbieter ausgewählt hat, wird der status() Callback wird aufgerufen. Es wird ein Registrierungs-Code bereitgestellt und die AccessEnabler-Bibliothek beginnt mit der Abfrage des Servers auf eine erfolgreiche Zweitbildschirmauthentifizierung.

Wenn der angegebene Registrierungs-Code für die erfolgreiche Authentifizierung auf dem zweiten Bildschirm verwendet wurde, wird die setAuthenticatiosStatus() Callback wird ausgelöst. An dieser Stelle sollte der Benutzer bei Apple SSO authentifiziert werden.

[Optional] Aufruf checkPreauthorizedResources(resources) , um zu überprüfen, welche Ressourcen der Benutzer anzeigen darf. Die resources parameter ist ein Array geschützter Ressourcen, die mit dem Authentifizierungstoken des Benutzers verknüpft sind. Eine Verwendung der Autorisierungsinformationen, die vom MVPD des Benutzers erhalten werden, besteht darin, Ihre Benutzeroberfläche zu dekorieren (z. B. gesperrte/entsperrte Symbole neben geschützten Inhalten).

• Trigger: preauthorizedResources() callback

• Ausführungspunkt: Nach Abschluss des Authentifizierungsablaufs

Wenn die Authentifizierung erfolgreich war, fahren Sie mit dem Autorisierungsfluss fort.

Aufruf getAuthorization() , um den Genehmigungsprozess einzuleiten.

• Abhängigkeit: Gültige ResourceID(s), die mit den MVPD(s) vereinbart wurde.
• Die Ressourcen-IDs sollten mit denen auf anderen Geräten oder Plattformen übereinstimmen und sind über MVPDs hinweg identisch. Informationen zu Ressourcen-IDs finden Sie unter Ermitteln geschützter Ressourcen

Validieren Sie Authentifizierung und Autorisierung.

• Wenn die Variable getAuthorization() Aufruf erfolgreich: Der Benutzer verfügt über gültige AuthN- und AuthZ-Token (der Benutzer ist authentifiziert und berechtigt, die angeforderten Medien zu sehen).

• Wenn getAuthorization() schlägt fehl: Untersuchen Sie die ausgelöste Ausnahme, um ihren Typ zu bestimmen (AuthN, AuthZ oder etwas Anderes):

  • Wenn es sich um einen Authentifizierungsfehler (AuthN) handelte, starten Sie den Authentifizierungsfluss neu.
  • Wenn es sich um einen Autorisierungsfehler (AuthZ) handelt, ist der Benutzer nicht berechtigt, das angeforderte Medium zu sehen und dem Benutzer sollte eine Fehlermeldung angezeigt werden.
  • Wenn ein anderer Fehlertyp aufgetreten ist (Verbindungsfehler, Netzwerkfehler usw.) zeigen Sie dem Benutzer eine entsprechende Fehlermeldung an.

Validieren Sie das Token für kurze Medien.
Verwenden Sie die Adobe Pass Authentication Media Token Verifier-Bibliothek, um das von der getAuthorization() Aufruf oben:

• Wenn die Validierung erfolgreich ist: Wiedergabe des angeforderten Mediums für den Benutzer.
• Wenn die Validierung fehlschlägt: Das AuthZ-Token war ungültig, die Medienanforderung sollte abgelehnt werden und dem Benutzer sollte eine Fehlermeldung angezeigt werden.

Kehren Sie zu Ihrem normalen Anwendungsfluss zurück.

Der Benutzer wählt das Medium aus, das angezeigt werden soll.

Sind die Medien geschützt? Ihre Anwendung prüft, ob die ausgewählten Medien geschützt sind:

• Wenn das ausgewählte Medium geschützt ist, startet Ihre Anwendung die Autorisierungsfluss höher.

• Wenn das ausgewählte Medium nicht geschützt ist, geben Sie das Medium für den Benutzer wieder.

Aufruf logout() , um den Benutzer abzumelden. AccessEnabler löscht alle zwischengespeicherten Werte und Token. Nachdem der Cache gelöscht wurde, führt der AccessEnabler einen Server-Aufruf durch, um die Server-seitigen Sitzungen zu bereinigen. Da der Server-Aufruf zu einer SAML-Umleitung zum IdP führen kann (dies ermöglicht die Sitzungsbereinigung auf der IdP-Seite), muss dieser Aufruf allen Umleitungen folgen. Aus diesem Grund muss dieser Aufruf innerhalb eines UIWebView/WKWebView- oder SFSafariViewController-Controllers verarbeitet werden.

a. Entsprechend dem gleichen Muster wie der Authentifizierungs-Workflow sendet die AccessEnabler-Domäne über die navigateToUrl: oder navigateToUrl:useSVC: Callback, um einen UIWebView/WKWebView- oder SFSafariViewController-Controller zu erstellen und diesen anzuweisen, die im Callback bereitgestellte URL zu laden url -Parameter. Dies ist die URL des Abmelde-Endpunkts auf dem Backend-Server.

b. Ihre Anwendung muss die Aktivität der UIWebView/WKWebView or SFSafariViewController steuern und den Moment erkennen, in dem eine bestimmte benutzerdefinierte URL geladen wird, da sie mehrere Umleitungen durchläuft. Beachten Sie, dass diese spezifische benutzerdefinierte URL tatsächlich ungültig ist und nicht für den Controller vorgesehen ist, sie tatsächlich zu laden. Sie darf von Ihrer Anwendung nur als Signal interpretiert werden, dass der Abmeldefluss abgeschlossen ist und dass es sicher ist, die UIWebView/WKWebView oder SFSafariViewController Controller. Wenn der Controller diese spezifische benutzerdefinierte URL lädt, muss Ihre Anwendung die UIWebView/WKWebView or SFSafariViewController Controller und Aufruf von AccessEnabler handleExternalURL:urlAPI-Methode. Im Fall von SFSafariViewControllerDer Controller muss verwendet werden, wenn die spezifische benutzerdefinierte URL von der application's custom scheme (zum Beispiel: adbe.u-XFXJeTSDuJiIQs0HVRAg://adobe.com). Andernfalls wird diese spezifische benutzerdefinierte URL durch die Variable ADOBEPASS_REDIRECT_URL Konstante (d. h. adobepass://ios.app).