プログラマーのエンタイトルメントフロー prog-entitlement-flow

概要 overview

このドキュメントでは、プログラマーの観点からの基本的なエンタイトルメントフローについて説明します。 ここで説明する基本的な TVE 統合以外の機能と使用例については、 プログラマーの使用例.

Adobe Pass認証は、両者に対して安全で一貫性のあるインターフェイスを提供することで、プログラマーと MVPD 間のエンタイトルメントフローを仲介します。 プログラマー側では、Adobe Pass Authentication は、次の 2 つの一般的なタイプのエンタイトルメントインターフェイスを提供します。

ここで示すプラットフォームに依存しない概要に加えて、クライアントレス API 固有の概要は、クライアントレス API ドキュメントに記載されています。 AccessEnabler は、サポート対象のプラットフォーム (Web 上では AS / JS、iOSでは Objective-C、Android では Java) でネイティブに動作します。 AccessEnabler API は、サポートされるプラットフォーム間で一貫しています。 AccessEnabler をサポートしていないすべてのプラットフォームは、同じクライアントレス API を使用します。

どちらのタイプのインターフェイスでも、Adobe Pass Authentication は、プログラマーのアプリとユーザーの MVPD の間のエンタイトルメントフローを安全に仲介します。

図： Adobe Pass Authentication Ecosystem

権利付与フロー entitlement-flow

基本的なエンタイトルメントフローを構成する次の 4 つの個別のサブフローがあります。

ユーザーがプログラマーのサイトに初めて訪問すると、エンタイトルメントフローは上記の順序で進みます。 ただし、以降の訪問では、認証および承認トークンの有効期限が切れているかどうか、または表示ポリシーによっては、ユーザーがサブフローの 1 つまたは 2 つしか経由しない場合があります。

起動フロー startup

プログラマーとデバイスの ID を確立し、初期化タスクを実行します。 これは、以降のすべての使用権限の呼び出しの前提条件です。

AccessEnabler

クライアントレス API

認証フロー authentication

認証が成功すると、デバイスとリクエスト元に関連付けられた AuthN トークンが生成されます。 認証が成功すると、認証の前提条件となります。

AccessEnabler

クライアントレス API

次の 2 つの点が真の場合、AuthN トークンは有効と見なされます。

汎用 AccessEnabler 初期認証ワークフロー generic-ae-initial-authn-flow

認証フロー authorization

認証は、保護されたコンテンツを表示するための前提条件です。 正常な認証により、AuthZ トークンと、セキュリティ上の理由からプログラマーのアプリに提供される短時間のみ有効なメディアトークンが生成されます。 承認ワークフローをサポートするには、必要なリクエスト元の設定を事前に実行し、 メディアトークン検証ツール. これらが完了したら、認証を開始できます。

保護されたリソースへのアクセスをユーザーがリクエストすると、アプリが認証を開始します。 リクエストされたリソース（例えば、チャネル、エピソードなど）を指定するリソース ID を渡します。 アプリは、まず、保存された認証トークンを確認します。 見つからない場合は、認証プロセスを開始します。

AccessEnabler

認証呼び出しの結果を処理するために、次のコールバック関数を提供します。

クライアントレス API

汎用 AccessEnabler 認証ワークフロー generic-ae-authr-wf

ログアウトフロー logout

現在のユーザーのエンタイトルメントフローに関連付けられたトークンやその他のデータをクリアします。

AccessEnabler

クライアントレス API

AccessEnabler の動作の理解 ae-behavior

AccessEnabler API 呼び出しはすべて非同期です（ただし、API リファレンスに記載されている例外は 1 つです）。 API は任意の回数呼び出すことができますが、呼び出しによってトリガーされるアクションが呼び出しがおこなわれたのと同じ順序で完了するという強力な保証はありません。 ( ただし、現在のFlash Playerランタイムは例外です。マルチスレッドではないので、呼び出しを確実におこないます。 do 呼び出された順に完了します )。

応答を区別し、応答を呼び出しとペアリングできるように、すべてのコールバックは入力パラメータをエコーバックします。 これには以下が含まれます。 setToken() およびtokenRequestFailed()( 最終的には、 checkAuthorization(). ( の checkAuthorization() コールバックを呼び出すと、使用したリソースがエコーバックされます )。 この機能を利用すると、どの応答がどの呼び出しに対応しているかを区別できます。 この機能を使用するには、次のようなコードを記述します。

    for each (resource in ["TNT", "CNN", "TBS", "AdultSwim"] ) {
         ae.checkAuthorization(resource);
    }

    // Success callback
    function setToken(resource, token) {
         // Use "resource" to figure
         // out which checkAuthorization
         // call triggered this response
    }

    // Old error callback
    function tokenRequestFailed(resource, error, details) {
         // use "resource" to figure
         // out in response to which
         // checkAuthorization call
         // this was triggered
    }

    // Error callback using new error api
    ae.bind("errorEvent',"errorHandler");

    function errorHandler(error) {
         if(error.resource) {
              // Use error.resource to figure
              // which checkAuthorization call
              // triggered this response
         }
    }

AEM の動作に関する FAQ ae-beh-faq

質問。 最初の呼び出しが終了する前に 2 回目の AccessEnabler 呼び出しを実行するとどうなりますか。

2 番目の呼び出しが実行されると（非同期通信）、最初の呼び出しが引き続き実行されます。

質問。 AccessEnabler がサポートする同時呼び出しの数は最大ですか。

AccessEnabler コードには制限が明示的に設定されていないので、使用可能なシステムリソースと MVPD の容量によってのみ制限されます。