程式設計師權益流程 prog-entitlement-flow
概觀 overview
本檔案從程式設計師的角度說明基本權益流程。 如需本文所說明基本TVE整合以外的功能和使用案例相關資訊，請參閱 程式設計師使用案例.
Adobe Pass驗證透過為雙方提供安全、一致的介面，調解程式設計師和MVPD之間的權益流程。 在程式設計師方面，Adobe Pass驗證提供兩種一般型別的權益介面：
- AccessEnabler — 一種使用者端元件，為可轉譯網頁的裝置（例如網頁應用程式、智慧型手機/平板電腦應用程式）上的應用程式提供API程式庫。
- 無使用者端API — 適用於無法轉譯網頁的裝置（例如機上盒、遊戲機、智慧型電視）的RESTful網路服務。 轉譯網頁的需求來自MVPD要求使用者在MVPD網站上驗證的需求。
除了這裡提供的平台中立概覽外，這裡還有無使用者端API專屬概觀：無使用者端API檔案。 AccessEnabler會在支援的平台上以原生方式執行(在Web上執行AS / JS、在iOS上執行Objective-C，以及在Android上執行Java)。 AccessEnabler API在支援的平台上保持一致。 所有不支援AccessEnabler的平台都使用相同的無使用者端API。
對於這兩種型別的介面，Adobe Pass驗證會安全地協調程式設計師的應用程式和使用者的MVPD之間的軟體權利檔案流程：
圖：Adobe Pass驗證生態系統
權益流程 entitlement-flow
基本權益流程共有四個不同的子流程：
使用者初次造訪程式設計師網站時，軟體權利檔案流程將依照上述順序進行。 不過，在後續的造訪中，根據驗證和授權權杖是否已過期，或根據檢視原則，使用者可能只會通過一兩個子流程。
啟動流程 startup
建立程式設計師與裝置的身分識別，執行初始化工作。 這是所有後續軟體權利檔案呼叫的先決條件。
AccessEnabler
-
setRequestor()— 透過AccessEnalber建立您的身分識別，並透過擴充功能建立Adobe Pass驗證伺服器。 此呼叫是權益流程其餘部分的先導。 例如，在JavaScript中：code language-javascript /* Define the requestor ID (Programmer/aggregator ID). */ var requestorID = "sample_requestor_Id"; ... // Callback indicating that the AccessEnabler swf has initialized function swfLoaded() { // AccessEnabler is loaded so we can use the API function it provides accessEnablerObject.setRequestor(requestorID); ... }
無使用者端API
\<REGGIE\_FQDN\>/reggie/v1/{requestorId}/regcode— 視平台而定，在您的應用程式呼叫regcode之前，可能會有需要完成的先決條件工作。 請參閱 無使用者端API檔案 以取得詳細資訊。 例如，Xbox平台會要求您在呼叫regcode之前完成規定的安全性步驟。
驗證流程 authentication
成功的驗證會產生繫結至裝置和請求者的AuthN權杖。 成功的驗證是取得授權的先決條件。
AccessEnabler
checkAuthentication()— 檢查本機權杖快取中是否存在有效的快取驗證權杖，而不會實際觸發完整驗證流程。 這會觸發setAuthenticationStatus()回呼函式。getAuthentication()— 起始完整的驗證流程。 如果成功，Adobe Pass驗證會產生AuthN權杖，並在使用者端上快取該權杖。 使用者登入其選取的MVPD網站，在iFrame、快顯視窗或Webview中顯示（視平台而定）。 這會觸發displayProviderDialog()。
無使用者端API
<FQDN>/.../checkauthn— 的Web服務版本checkAuthentication()以上。<FQDN>/.../config— 將MVPD清單傳回至第二熒幕應用程式。<FQDN>/.../authenticate— 從第二熒幕應用程式起始驗證流程，將使用者重新導向至其選取的MVPD登入。 如果成功，Adobe Pass驗證會產生AuthN權杖並將其儲存在伺服器上，然後使用者會返回其原始裝置以完成權利流程。
如果下列兩點為True，則AuthN代號視為有效：
- AuthN權杖未過期
- 與AuthN權杖關聯的MVPD位於目前要求者ID的允許MVPD清單中
通用AccessEnabler初始驗證工作流程 generic-ae-initial-authn-flow
-
您的應用程式會透過呼叫來起始驗證工作流程
getAuthentication()，會檢查是否有有效的快取驗證Token。 此方法有一個選擇性redirectURL引數；如果未提供redirectURL，在成功驗證後，使用者會回到初始化驗證的URL。 -
AccessEnabler決定目前的驗證狀態。 如果使用者目前已驗證，AccessEnabler會呼叫
setAuthenticationStatus()回呼函式，傳遞驗證狀態以表示成功。 -
如果使用者未驗證，則AccessEnabler會透過判斷使用者的上次驗證嘗試是否在指定的MVPD上成功來繼續驗證流程。 如果已快取MVPD ID且
canAuthenticate標幟為true或使用setSelectedProvider()，使用者不會因為MVPD選取對話方塊而收到提示。 驗證流程會繼續使用MVPD的快取值（也就是上次成功驗證期間使用的MVPD）。 系統會呼叫後端伺服器，並將使用者重新導向至MVPD登入頁面。 -
如果未快取任何MVPD ID，且未使用選取任何MVPD
setSelectedProvider()或canAuthenticate標幟設為false，則displayProviderDialog()系統會呼叫callback。 此回呼會指示您的應用程式建立UI，向使用者顯示可從中進行選擇的MVPD清單。 提供了一系列MVPD物件，其中包含您建置MVPD選取器所需的資訊。 每個MVPD物件描述MVPD實體，並包含MVPD的ID和可以找到MVPD標誌的URL等資訊。 -
選取MVPD後，您的應用程式必須通知AccessEnabler使用者所做的選擇。 對於非Flash使用者端，一旦使用者選取想要的MVPD，您會透過呼叫
setSelectedProvider()方法。 Flash使用者端改為傳送共用的MVPDEvent屬於「」型別mvpdSelection「」，傳遞選取的提供者。 -
當通知AccessEnabler使用者的MVPD選擇時，會進行網路呼叫至後端伺服器，並將使用者重新導向至MVPD登入頁面。
-
在驗證工作流程中，AccessEnabler會與Adobe Pass Authentication和選取的MVPD通訊，以索取使用者的認證（使用者ID和密碼）並驗證其身分。 雖然有些MVPD會重新導向至自己的登入網站，有些則需要您在iFrame中顯示其登入頁面。 您的頁面必須包含建立iFrame的回呼，以備客戶選擇其中一個MVPD時使用。.
-
使用者成功登入後，AccessEnabler會擷取驗證Token，並通知您的應用程式驗證流程已完成。 AccessEnabler呼叫
setAuthenticationStatus()具有狀態代碼1的回呼，表示成功。 如果在執行這些步驟期間發生錯誤，setAuthenticationStatus()系統會以狀態碼0觸發回呼，表示驗證失敗以及對應的錯誤碼。
授權流程 authorization
授權是檢視受保護內容的先決條件。 成功的授權會產生AuthZ權杖，以及提供給程式設計師應用程式以用於安全目的的短期媒體權杖。 請注意，若要支援授權工作流程，您先前必須已執行必要的請求者設定，並已整合 媒體權杖驗證器. 完成這些步驟後，您就可以啟動授權。
當使用者請求存取受保護的資源時，您的應用程式會起始授權。 您可以傳遞指定請求資源的資源ID （例如，頻道、集數等）。 您的應用程式會先檢查是否有已儲存的驗證Token。 如果找不到，您就會啟動驗證程式。
AccessEnabler
-
checkAuthorization()— 檢查授權，而不啟動完整的授權流程。 這通常用於更新程式設計師應用程式UI中顯示的狀態資訊。 -
getAuthorization()— 起始完整授權流程。
您提供下列回呼函式來處理授權呼叫的結果：
-
setToken()— 如果先前驗證成功且授權成功，AccessEnabler會呼叫setToken()回呼函式，傳遞短期媒體權杖，表示成功完成Adobe Pass驗證許可權流程。 (在允許使用者檢視受保護的內容之前，程式設計師的應用程式會使用媒體權杖驗證器來檢查媒體權杖的有效性。 -
tokenRequestFailed()— 如果使用者未獲授權使用要求的資源（或查詢因任何其他原因而失敗），AccessEnabler會呼叫此回呼函式（加上您自己的錯誤報告函式），傳遞失敗的詳細資料。
無使用者端API
\<FQDN\>/.../authorize— 起始完整授權流程。
通用AccessEnabler授權工作流程 generic-ae-authr-wf
-
提供回呼函式，使用Access Enabler註冊指派的程式設計人員GUID。
setReqestor(). 成功下載AccessEnabler時，會呼叫此回呼函式。 -
呼叫
getAuthorization()當使用者請求存取受保護資源時。 使用getAuthorization()，傳遞指定請求資源的資源ID （例如，頻道、集數等）。 AccessEnabler會尋找快取的驗證Token，以隨授權要求傳遞。 如果找不到，則會起始驗證流程。 -
提供回呼函式以處理授權結果：
-
setToken()— 如果授權成功，或使用者先前已獲得授權，Access Enabler會繼續授權程式，方法是呼叫setToken()回呼函式，傳遞短期授權權杖。 -
tokenRequestFailed()— 如果使用者未被授權使用要求的資源（或查詢因任何其他原因而失敗），AccessEnabler會呼叫您已註冊的任何錯誤報告函式，以及tokenRequestFailed()回呼，傳遞失敗的詳細資料。
-
登出流程 logout
清除與目前使用者軟體權利檔案流程關聯的權杖和其他資料。
AccessEnabler
logout()
無使用者端API
\<FQDN\>/.../logout
瞭解AccessEnabler行為 ae-behavior
所有AccessEnabler API呼叫為非同步（但有一個例外，記錄在API參考資料中）。 您可以呼叫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行為常見問題集 ae-beh-faq
問題。 如果在第一個呼叫完成前進行第二個AccessEnabler呼叫，會發生什麼事？
當第二個呼叫執行時，第一個呼叫會繼續執行（非同步通訊）。
問題。 AccessEnabler可支援的同步呼叫數是否有上限？
AccessEnabler程式碼未明確設定任何限制，因此您僅受可用系統資源及MVPD容量的限制。