Guide pas à pas API REST V2 (serveur à serveur) rest-api-v2-cookbook-server-to-server

Communiquez avec le service Adobe Pass au nom de l’application de diffusion en continu.

Collectez et transmettez un identifiant d’appareil unique pour l’appareil de diffusion en continu, comme l’exige l’en-tête AP-Device-Identifier.

Collectez et transmettez des informations précises sur l’appareil de diffusion en continu, y compris le port source et les détails spécifiques à l’appareil, comme l’exige l’en-tête X-Device-Info.

Collectez et transmettez l’adresse IP de l’appareil de diffusion en continu comme l’exige l’en-tête X-Forwarded-For.

Stockez en toute sécurité des paramètres tels que l’identifiant de l’appareil, l’identifiant client et le secret client dans l’application de diffusion en continu ou le service de programmation.

Formatez et envoyez les données conformément aux MVPD et aux applications intégrées, y compris l’adresse IP de l’appareil, le port source, les informations spécifiques à l’appareil, le SMS et les identifiants facultatifs tels que l’ECID.

Conservez et gérez en toute sécurité les certificats partagés avec Adobe pour la transmission de métadonnées d’utilisateur chiffrées.

Respectez le profil d’authentification et la validité de la décision d’autorisation lors de la mise en cache, en veillant à ce que les états d’authentification et d’autorisation soient invalidés lorsque vous recevez une notification.

Renvoyez les décisions d’autorisation et les instructions pertinentes à l’application de streaming.

Le service Adobe Pass fonctionne sur plusieurs centres de données géographiquement dispersés aux États-Unis afin d’optimiser les performances et de minimiser la latence.

• Le service de programmation doit adopter une stratégie d’infrastructure similaire, afin d’assurer des temps de réponse de faible latence de la part d’Adobe Pass.

Le programmeur doit fournir la plage d’adresses IP publique de son environnement de production.

• Ces adresses IP seront ajoutées à une liste autorisée dans l’infrastructure Adobe Pass.

Le service de programmation doit limiter la mise en cache DNS à un maximum de 30 secondes afin de permettre un réacheminement dynamique au cas où Adobe devrait rediriger le trafic en raison de l’indisponibilité d’un centre de données.

Il doit permettre de tester les versions avant le déploiement en production.

Elle doit rester fonctionnellement similaire à la production, ce qui permet des tests réalistes.

Idéalement, l’environnement d’évaluation doit être connecté aux environnements de test Adobe Pass afin de :

• Permet aux programmeurs de tester l’infrastructure d’Adobe.

• Activez Adobe pour faciliter les tests et le dépannage si nécessaire.

Récupérer les informations d’identification du client : le service de programmation récupère les informations d’identification du client en appelant le point d’entrée /o/client/register.

• Le service de programmation ou l’application de programmation doivent stocker les informations d’identification du client et les utiliser indéfiniment lorsqu’ils doivent récupérer un jeton d’accès.

Récupérer le jeton d’accès : le service de programmation récupère le jeton d’accès en appelant le point d’entrée /o/client/token.

• Le service ou l’application de programmation doit stocker et utiliser le jeton d’accès jusqu’à son expiration, puis le supprimer et en obtenir un nouveau.

Récupérer les profils : le service de programmation recherche les profils existants pour le compte de l’application de streaming en appelant le point d’entrée /api/v2/{serviceProvider}/profiles.

Scénario 1 : il existe des profils existants, le service de programmation peut passer à la phase de préautorisation ou à la phase d’autorisation.

Scénario 2 : il n’existe aucun profil existant, le service de programmation peut passer à l’étape suivante pour Authentifier l’utilisateur.

Scénario 3 : il n’existe aucun profil, le service de programmation peut procéder à la fourniture d’un accès temporaire à l’utilisateur par le biais de la fonctionnalité TempPass.

• Ce scénario n’entre pas dans le cadre de ce document. Pour plus d’informations🔗 consultez la documentation Flux d’accès temporaires .

Récupérer la configuration : le service de programmation récupère la liste des MVPD disponibles en appelant le point d’entrée /api/v2/{serviceProvider}/configuration.

• Le service de programmation peut mettre en œuvre un mécanisme de filtrage personnalisé pour affiner la liste des MVPD à partir de la réponse de configuration, de sorte que l’application de diffusion en continu affiche uniquement les fournisseurs prévus tout en masquant les autres (par exemple, les MVPD en cours de développement, les MVPD de test, TempPass). Cela permet de s’assurer que les utilisateurs disposent d’une sélection organisée lors du choix de leur fournisseur de télévision.

Créer une session d’authentification : le service de programmation lance une session d’authentification en appelant le point d’entrée /api/v2/{serviceProvider}/sessions.

• Le service de programmation doit renvoyer les code et les url à l’application de diffusion en continu.

Scénario 1 : l’application de diffusion en continu peut ouvrir un navigateur ou une vue web. Elle doit donc charger le url d’authentification.

• L’utilisateur envoie son nom d’utilisateur et son mot de passe dans la page de connexion de MVPD. Une fois l’authentification réussie, la redirection finale affiche une page de réussite.

Scénario 2 : l’application de diffusion en continu ne peut pas ouvrir de navigateur. Elle doit donc afficher le code d’authentification. Une application web distincte est nécessaire pour inviter l’utilisateur à saisir le code, à créer le url d’authentification et à l’ouvrir : /api/v2/authenticate/{serviceProvider}/{code}.

• L’utilisateur envoie son nom d’utilisateur et son mot de passe dans la page de connexion de MVPD. Une fois l’authentification réussie, la redirection finale affiche une page de réussite.

Récupérer le profil pour un code spécifique : le service de programmation doit implémenter un mécanisme d’interrogation à l’aide de l’code pour vérifier si le profil a été généré et enregistré avec succès en appelant le point d’entrée /api/v2/{serviceProvider}/profiles/code/{code}.

• Le service de programmation doit démarrer le mécanisme d’interrogation dans les conditions suivantes :

  • Authentification effectuée dans l’application principale (écran) : le service de programmation doit lancer l’interrogation lorsque l’utilisateur atteint la page de destination finale, une fois que le composant de navigateur charge l’URL spécifiée pour le paramètre redirectUrl dans la requête de point d’entrée Sessions.

  • Authentification effectuée dans une application secondaire (écran) : l’application du service de programmation doit lancer l’interrogation dès que l’utilisateur lance le processus d’authentification, juste après avoir reçu la réponse du point d’entrée Sessions et affiché le code d’authentification à l’utilisateur.

• Le service de programmation doit arrêter le mécanisme d’interrogation dans les conditions suivantes :

  • Authentification réussie : les informations de profil de l’utilisateur sont récupérées avec succès, confirmant leur statut d’authentification. À ce stade, l’interrogation n’est plus nécessaire.

  • Session d’authentification et expiration du code : la session d’authentification et le code expirent, comme indiqué par la date et l’heure notAfter (par exemple, 30 minutes) dans la réponse de point d’entrée Sessions. Si cela se produit, l’utilisateur ou l’utilisatrice doit redémarrer le processus d’authentification et l’interrogation à l’aide du code d’authentification précédent doit être arrêtée immédiatement.

  • Nouveau code d’authentification généré : si l’utilisateur demande un nouveau code d’authentification sur l’appareil principal (écran), la session existante n’est plus valide et l’interrogation à l’aide du code d’authentification précédent doit être arrêtée immédiatement.

• Le service de programmation doit configurer la fréquence du mécanisme d’interrogation dans les conditions suivantes :

  • Authentification effectuée dans l’application principale (écran) : le service de programmation doit effectuer une interrogation toutes les 3 à 5 secondes ou plus.

  • Authentification effectuée dans une application secondaire (écran) : le service de programmation doit interroger toutes les 3 à 5 secondes ou plus.

• Le service de programmation doit mettre en cache certaines parties des informations de profil de l’utilisateur dans un stockage persistant afin d’éviter les requêtes inutiles et d’améliorer l’expérience de l’utilisateur.

Récupérer les décisions de préautorisation : le service de programmation récupère les décisions de préautorisation pour une liste de ressources en appelant le point d’entrée /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}.

• Le service de programmation doit transmettre la liste des décisions d’autorisation et de refus de préautorisation à l’application de diffusion en continu.

• Le service de programmation n’est pas nécessaire pour stocker les décisions de préautorisation dans un stockage persistant. Cependant, il est recommandé de mettre en cache les décisions d’autorisation en mémoire pour améliorer l’expérience de l’utilisateur. Cela permet d’éviter les appels inutiles de ressources déjà préautorisées, ce qui réduit la latence et améliore les performances.

• Le service de programmation peut déterminer la raison d’un refus de décision de préautorisation en examinant le code d’erreur et le messageinclus dans la réponse à partir du point d’entrée de préautorisation des décisions . Ces détails fournissent des informations sur la raison spécifique pour laquelle la demande de préautorisation a été refusée, ce qui permet d’informer l’expérience utilisateur ou de déclencher toute gestion nécessaire dans l’application. Assurez-vous que tout mécanisme de reprise implémenté pour récupérer les décisions de préautorisation ne génère pas de boucle sans fin si la décision de préautorisation est refusée. Envisagez de limiter les reprises à un nombre raisonnable et de gérer les refus de manière élégante en présentant des commentaires clairs à l’utilisateur.

• Le service de programmation peut obtenir une décision de préautorisation pour un nombre limité de ressources dans une seule requête API, généralement jusqu’à 5, en raison des conditions imposées par les MVPD. Ce nombre maximal de ressources peut être consulté et modifié après accord avec les MVPD via le tableau de bord Adobe Pass TVE Dashboard par l’un des administrateurs de votre entreprise ou par un représentant Adobe Pass Authentication agissant en votre nom.

Récupérer la décision d’autorisation : le service de programmation récupère la décision d’autorisation pour une ressource spécifique transmise par l’application de diffusion en continu en appelant le point d’entrée /api/v2/{serviceProvider}/decision/authorize/{mvpd}.

• Le service de programmation n’est pas nécessaire pour stocker les décisions d’autorisation dans un stockage persistant.

• Le service de programmation peut déterminer la raison d’un refus d’autorisation en examinant le code d’erreur et le messageinclus dans la réponse à partir du point d’entrée d’autorisation des décisions . Ces détails fournissent à insight la raison spécifique pour laquelle la demande d’autorisation a été refusée, ce qui permet d’informer l’expérience utilisateur ou de déclencher toute gestion nécessaire dans l’application de diffusion en continu. Assurez-vous que tout mécanisme de reprise implémenté pour récupérer les décisions d’autorisation ne génère pas de boucle sans fin si la décision d’autorisation est refusée. Envisagez de limiter les reprises à un nombre raisonnable et de gérer les refus de manière élégante en présentant des commentaires clairs à l’utilisateur.

• Le service de programmation peut évaluer d'autres règles métier et renvoyer une décision d'autorisation appropriée à l'application de streaming.

• Le service de programmation n’est pas nécessaire pour actualiser un jeton de média expiré pendant que le flux est en cours de lecture. Si le jeton de média expire pendant la lecture, le flux doit pouvoir continuer sans interruption. Cependant, le client doit demander une nouvelle décision d’autorisation et obtenir un nouveau jeton de média la prochaine fois que l’utilisateur tente de lire une ressource.

• Le service de programmation peut obtenir une décision d’autorisation pour un nombre limité de ressources dans une seule requête API, généralement jusqu’à 1, en raison des conditions imposées par les MVPD.

Lancer la déconnexion d’Adobe Pass : le service de programmation lance le flux de déconnexion comme demandé par l’application de diffusion en continu en appelant le point d’entrée /api/v2/{serviceProvider}/logout/{mvpd}.

• Le service de programmation peut nettoyer toutes les informations qu’il stocke sur l’utilisateur authentifié.

• Le service de programmation doit suivre les instructions fournies dans les attributs actionName et actionType de la réponse de point d’entrée de déconnexion pour s’assurer que le processus de déconnexion est correctement terminé.

  • Si l’attribut actionType dans la réponse est défini sur « interactif », le service de programmation doit renvoyer la valeur de l’attribut url à l’application de diffusion en continu.

    • Scénario 1 : l’application de diffusion en continu peut ouvrir un navigateur ou une vue web. Elle doit donc charger le url de déconnexion.

    • Scénario 2 : l’application de diffusion en continu ne peut pas ouvrir de navigateur. Par conséquent, le processus de déconnexion peut être arrêté, car la session MVPD n’a pas été conservée dans le cache du navigateur d’un appareil de diffusion en continu.