Manuel d’intégration d’Amazon FireOS (hérité) amazon-fireos-integration-cookbook

Créez vos fonctions de rappel :

• setRequestorComplete()

  • Déclenché par setRequestor(), renvoie un succès ou un échec. La réussite indique que vous pouvez poursuivre les appels de droits.

• displayProviderDialog(mvpds)

  • Déclenché par getAuthentication() uniquement si l’utilisateur n’a pas sélectionné de fournisseur (MVPD) et n’est pas encore authentifié. Le paramètre mvpds est un tableau de fournisseurs disponibles pour l’utilisateur.

• setAuthenticationStatus(status, reason)

  • Déclenché par checkAuthentication() à chaque fois. Déclenché par getAuthentication() uniquement si l’utilisateur est déjà authentifié et a sélectionné un fournisseur.

  • Le statut renvoyé est authentifié ou non authentifié. La raison décrit un échec d’authentification ou une action de déconnexion.

• navigateToUrl(url)

  • Ignorée dans AmazonFireOS SDK, la méthode est utilisée sur les plateformes Android où est déclenchée par getAuthentication() une fois que l’utilisateur a sélectionné un MVPD. Le paramètre url indique l’emplacement de la page de connexion de MVPD.

• sendTrackingData(event, data)

  • Déclenché par checkAuthentication(), getAuthentication(), checkAuthorization(), getAuthorization(), setSelectedProvider().
    Le paramètre event indique quel événement de droit s’est produit ; le paramètre data est une liste de valeurs relatives à l’événement.

• setToken(token, resource)

  • Déclenché par checkAuthorization() et getAuthorization() après une autorisation réussie d’affichage d’une ressource.
  • Le paramètre token est le jeton de média de courte durée ; le paramètre resource est le contenu que l’utilisateur est autorisé à afficher.

• tokenRequestFailed(resource, code, description)

  • Déclenché par checkAuthorization() et getAuthorization() après une autorisation infructueuse.
  • Le paramètre resource correspond au contenu que l’utilisateur tentait d’afficher ; le paramètre code correspond au code d’erreur indiquant le type d’échec ; le paramètre description décrit l’erreur associée au code d’erreur.

• selectedProvider(mvpd)

  • Déclenché par getSelectedProvider().
  • Le paramètre mvpd fournit des informations sur le fournisseur sélectionné par l’utilisateur ou l’utilisatrice.

• setMetadataStatus(metadata, key, arguments)

  • Déclenché par getMetadata().
  • Le paramètre metadata fournit les données spécifiques que vous avez demandées ; le paramètre key est la clé utilisée dans la requête getMetadata() ; et le paramètre arguments est le même dictionnaire que celui transmis à getMetadata().

• preauthorizedResources(resources)

  • Déclenché par checkPreauthorizedResources().
  • Le paramètre authorizedResources présente les ressources que l’utilisateur est autorisé à afficher.

Démarrez l’application de niveau supérieur.

Lancer l’authentification Adobe Pass.

1. Appelez getInstance pour créer une instance unique de l’AccessEnabler d’authentification Adobe Pass.

   • Adobe Pass Dépendance : Bibliothèque FireOS native d’authentification Amazon (AccessEnabler)

2. Appelez setRequestor() pour établir l’identité du programmeur ; transmettez le requestorID du programmeur et (éventuellement) un tableau de points d’entrée d’authentification Adobe Pass.

   • Dépendance : ID de demandeur d’authentification Adobe Pass valide (demandez l’aide de votre gestionnaire de compte d’authentification Adobe Pass).

   • Rappel Triggers: setRequestorComplete()

Aucune demande de droit ne peut être traitée tant que l’identité du demandeur n’est pas entièrement établie. Cela signifie effectivement que, pendant que setRequestor() est toujours en cours d’exécution, toutes les demandes de droits suivantes (par exemple, checkAuthentication()) sont bloquées.

Vous disposez de deux options de mise en œuvre : une fois les informations d’identification du demandeur envoyées au serveur principal, la couche d’application de l’interface utilisateur peut choisir l’une des deux approches suivantes :

1. Attendez le déclenchement du rappel setRequestorComplete() (partie du délégué AccessEnabler). Cette option offre la plus grande certitude quant à la réalisation de lsetRequestor()opération. Elle est donc recommandée pour la plupart des implémentations.
2. Continuez sans attendre le déclenchement du rappel setRequestorComplete() et commencez à émettre des demandes de droits. Ces appels (checkAuthentication, checkAuthorization, getAuthentication, getAuthorization, checkPreauthorizedResource, getMetadata, logout) sont mis en file d'attente par la bibliothèque AccessEnabler, qui effectuera les appels réseau réels après la setRequestor(). Cette option peut parfois être interrompue si, par exemple, la connexion réseau est instable.

Appelez checkAuthentication() pour vérifier une authentification existante sans initier le flux d’authentification complet. Si cet appel réussit, vous pouvez passer directement au flux d’autorisation. Dans le cas contraire, passez au flux d’authentification.

Appelez getAuthentication() pour lancer le flux d’authentification ou pour obtenir la confirmation que l’utilisateur est déjà authentifié.

Triggers:

• Le rappel setAuthenticationStatus() , si l’utilisateur est déjà authentifié. Dans ce cas, passez directement au flux d’autorisation.
• Le rappel displayProviderDialog() , si l’utilisateur n’est pas encore authentifié.

Présentez à l'utilisateur la liste des fournisseurs envoyés à displayProviderDialog().

Une fois que l'utilisateur a sélectionné un fournisseur, une vue Web ouvre la page du fournisseur pour permettre à l'utilisateur de se connecter

Une fois la connexion établie par l'utilisateur, WebView se ferme.

appelez getAuthenticationToken(), qui demande au AccessEnabler de récupérer le jeton d’authentification du serveur principal.

[Facultatif] Appelez checkPreauthorizedResources(resources) pour vérifier quelles ressources l’utilisateur est autorisé à afficher. Le paramètre resources est un tableau de ressources protégées associé au jeton d’authentification de l’utilisateur.

Triggers: rappel preAuthorizedResources()
Point d’exécution : après le flux d’authentification terminé

Si l’authentification a réussi, passez au flux d’autorisation.

Appelez getAuthorization() pour lancer le flux d’autorisation.

Dépendance : identifiant(s) de ressource valide(s) convenu(s) avec le ou les MVPD.

Remarque : ResourceID doivent être identiques à ceux utilisés sur d’autres appareils ou plateformes et seront identiques sur tous les MVPD.

Validez l’authentification et l’autorisation.

• Si l’appel getAuthorization() réussit : l’utilisateur dispose de jetons AuthN et AuthZ valides (l’utilisateur est authentifié et autorisé à regarder le média demandé).

• Si getAuthorization() échoue : examinez l’exception renvoyée pour déterminer son type (AuthN, AuthZ ou autre chose) :

  • S’il s’agissait d’une erreur d’authentification (AuthN), redémarrez le flux d’authentification.
  • S’il s’agissait d’une erreur d’autorisation (AuthZ), l’utilisateur n’est pas autorisé à regarder le média demandé et un message d’erreur doit s’afficher à l’intention de l’utilisateur.
  • S’il y a eu un autre type d’erreur (erreur de connexion, erreur réseau, etc.), affichez un message d’erreur approprié à l’intention de l’utilisateur.

Validez le jeton de média court.

Utilisez la bibliothèque Vérificateur de jeton de média d’authentification Adobe Pass pour vérifier le jeton de média de courte durée renvoyé par l’appel getAuthorization() ci-dessus :

• Si la validation réussit : lisez le média demandé pour l’utilisateur.
• Si la validation échoue : le jeton AuthZ n’était pas valide, la requête de média doit être refusée et un message d’erreur doit s’afficher à l’intention de l’utilisateur.

Retournez à votre flux d’application normal.

L’utilisateur sélectionne le média à afficher.

Les médias sont-ils protégés ? Votre application vérifie si le média sélectionné est protégé :

• Si le média sélectionné est protégé, votre application lance le flux d’autorisation ci-dessus.
• Si le média sélectionné n’est pas protégé, lisez le média pour l’utilisateur.

Appelez logout() pour déconnecter l’utilisateur. Le AccessEnabler efface toutes les valeurs mises en cache et les jetons obtenus par l’utilisateur pour le MVPD actuel pour tous les demandeurs partageant la connexion via l’authentification unique. Après avoir effacé le cache, le AccessEnabler effectue un appel au serveur pour nettoyer les sessions côté serveur. Notez que puisque l’appel au serveur peut entraîner une redirection SAML vers l’IdP (cela permet le nettoyage de la session du côté IdP), cet appel doit suivre toutes les redirections. Pour cette raison, cet appel sera géré à l'intérieur d'un contrôle WebView, invisible pour l'utilisateur.

Remarque : le flux de déconnexion diffère du flux d’authentification dans la mesure où l’utilisateur n’est pas tenu d’interagir avec le WebView de quelque manière que ce soit. Il est donc possible (et recommandé) de rendre le contrôle WebView invisible (c'est-à-dire masqué) pendant le processus de déconnexion.