Programmerarens tillståndsflöde prog-entitlement-flow

Ökning overview

Det här dokumentet beskriver det grundläggande tillståndsflödet från programmerarens perspektiv. Mer information om funktioner och användningsområden utöver den grundläggande TVE-integreringen som beskrivs här finns i Exempel på programmeringsanvändning.

Adobe Pass Authentication medierar tillståndsflödet mellan programmerare och distributörer av videoprogrammeringstjänster genom att tillhandahålla säkra, enhetliga gränssnitt för båda parter. På programmerarens sida har Adobe Pass Authentication två typer av tillståndsgränssnitt:

Förutom den plattformsneutrala översikt som presenteras här finns det en klientlös API-specifik översikt här: API-dokumentation utan klient. AccessEnabler kan köras direkt på plattformar som stöds (AS/JS på webben, Objective-C på iOS och Java på Android). API:erna för AccessEnabler är konsekventa på de plattformar som stöds. Alla plattformar som inte stöder AccessEnabler använder samma klientlösa API.

För båda gränssnittstyperna medierar Adobe Pass Authentication på ett säkert sätt tillståndsflödet mellan programmerarens app och användarens MVPD:

Figur: Adobe Pass-ekosystem för autentisering

Tillståndsflöde entitlement-flow

Det finns fyra olika delflöden som utgör det grundläggande berättigandet
flöde:

På en användares första besök på en programmerares webbplats fortsätter tillståndsflödet i den ordning som anges ovan. Vid efterföljande besök, beroende på om autentiserings- och auktoriseringstoken har upphört att gälla eller inte, eller beroende på visningsprofiler, kan en användare bara gå igenom ett eller två av delflödena.

Startflöde startup

Fastställer programmerarens och enhetens identitet, utför initieringsuppgifter. Detta är en förutsättning för alla efterföljande berättigandeanrop.

AccessEnabler

Klientlöst API

Autentiseringsflöde authentication

En AuthN-token som är kopplad till enheten och den som gjorde begäran genereras. Lyckad autentisering är en förutsättning för auktorisering.

AccessEnabler

Klientlöst API

En AuthN-token betraktas som giltig om följande två punkter är sanna:

Allmänt arbetsflöde för inledande autentisering av AccessEnabler generic-ae-initial-authn-flow

Auktoriseringsflöde authorization

Behörighet krävs för att visa skyddat innehåll. Auktoriseringen genererar en AuthZ-token tillsammans med en kort Media Token som tillhandahålls till programmerarens app av säkerhetsskäl. Observera, att för att ge stöd för auktoriseringsarbetsflödet måste du tidigare ha utfört den nödvändiga konfigureringen av begärande och ha integrerat verifieraren för medietoken. När dessa är klara kan du initiera auktoriseringen.

Ditt program initierar auktorisering när en användare begär åtkomst till en skyddad resurs. Du skickar ett resurs-ID som anger den begärda resursen (till exempel en kanal, ett avsnitt osv.). Ditt program söker först efter en lagrad autentiseringstoken. Om det inte går att hitta någon initierar du autentiseringsprocessen.

AccessEnabler

Du tillhandahåller följande callback-funktioner för att hantera resultatet av
Ansökan om tillstånd:

Klientlöst API

Allmänt arbetsflöde för åtkomstaktivering generic-ae-authr-wf

Utloggningsflöde logout

Rensar tokens och andra data som är kopplade till den aktuella användarens tillståndsflöde.

AccessEnabler

Klientlöst API

Förstå AccessEnabler-beteendet ae-behavior

Alla API-anrop för AccessEnabler är asynkrona (med ett undantag som anges i API-referenserna). Du kan anropa ett API ett godtyckligt antal gånger, men det finns ingen stark garanti för att de utlösta åtgärderna
Utlysningen ska genomföras i den ordning som utlysningen gjordes. (Ett undantag till detta är den aktuella Flashens Player körningsmiljö. Om den inte är flertrådig säkerställs anropen do i ordningen
de kallas.)

För att kunna skilja på svaren och kunna koppla ihop svaren med anrop, återställer alla återanrop sina indataparametrar. Detta inkluderar setToken() ochtokenRequestFailed(), som utlöses av checkAuthorization(). (För checkAuthorization() återanrop återställs den använda resursen.) Genom att utnyttja den här funktionen kan du se vilket svar som motsvarar vilket samtal. Om du vill använda den här funktionen kan du koda något av följande:

    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
         }
    }

Vanliga frågor om AE-beteende ae-beh-faq

Fråga. Vad händer om jag gör ett andra AccessEnabler-anrop innan det första anropet avslutas?

Det första anropet fortsätter att köras när det andra anropet körs (asynkron kommunikation).

Fråga. Finns det ett maximalt antal samtidiga anrop som AccessEnabler kan stödja?

Ingen gräns anges uttryckligen i AccessEnabler-koden, så du begränsas bara av dina tillgängliga systemresurser och av MVPD:s kapacitet.