De machtigingsstroom van de programmeur prog-entitlement-flow

Overzicht overview

In dit document wordt de elementaire machtigingsstroom vanuit het perspectief van de programmeur beschreven. Voor informatie over functies en gebruiksgevallen die verder gaan dan de hier besproken elementaire TVE-integratie, raadpleegt u Gebruiksgevallen voor programmeerprogramma's.

De Authentificatie van Adobe Pass bemiddelen de machtigingsstroom tussen Programmers en MVPDs door veilige, verenigbare interfaces voor beide partijen te verstrekken. Aan de kant van de programmeur biedt Adobe Pass Authentication twee algemene typen machtigingsinterface:

Naast het platformneutrale overzicht dat hier wordt gepresenteerd, is er hier een API-specifiek overzicht zonder clips: documentatie voor de API zonder clips. AccessEnabler wordt native uitgevoerd op ondersteunde platforms (AS / JS op internet, doelstelling-C op iOS en Java op Android). De API's van AccessEnabler zijn consistent op alle ondersteunde platforms. Alle platforms die geen ondersteuning bieden voor AccessEnabler gebruiken dezelfde API zonder Clientless.

Voor beide typen interfaces zorgt Adobe Pass-verificatie veilig voor de overdracht van bevoegdheden tussen de toepassing van de programmeur en de MVPD van de gebruiker:

Afbeelding: Adobe Pass Authentication Ecosystem

Entitlement Flow entitlement-flow

Er zijn vier verschillende substromen die de basismachtigingsstroom vormen:

Tijdens het eerste bezoek van een gebruiker aan de site van een programmeur gaat de machtigingsstroom verder in de bovenstaande volgorde. Nochtans, bij verdere bezoeken, afhankelijk van of de authentificatie en toestemmingstokens al dan niet zijn verlopen, of afhankelijk van het bekijken van beleid, zou een gebruiker slechts door één of twee van de substromen kunnen gaan.

Stroom opstarten startup

Vestigt de identiteit van de Programmer en het apparaat, voert initialisatietaken uit. Dit is een voorwaarde voor alle volgende machtigingsoproepen.

AccessEnabled

Clientloze API

Verificatiestroom authentication

De succesvolle authentificatie produceert een teken AuthN verbonden aan het apparaat en de aanvrager. Succesvolle verificatie is een voorwaarde voor autorisatie.

AccessEnabled

Clientloze API

Een token AuthN wordt als geldig beschouwd als de volgende twee punten waar zijn:

Generic AccessEnabler Initial Authentication Workflow generic-ae-initial-authn-flow

Autorisatiestroom authorization

Autorisatie is een eerste vereiste voor het weergeven van beveiligde inhoud. Succesvolle autorisatie genereert een AuthZ-token, samen met een kortstondig Media Token dat voor beveiligingsdoeleinden aan de app van de programmeur wordt geleverd. Ter ondersteuning van de workflow voor machtigingen moet u de vereiste instellingen voor de aanvrager hebben uitgevoerd en de Verificator mediatokens. Met deze voltooide, kunt u vergunning in werking stellen.

Uw app start een autorisatie wanneer een gebruiker toegang tot een beveiligde bron aanvraagt. U geeft een bron-id door die de gewenste bron opgeeft (bijvoorbeeld een kanaal, aflevering, enz.). Uw app controleert eerst op een opgeslagen verificatietoken. Als er geen wordt gevonden, start u het verificatieproces.

AccessEnabled

U verstrekt de volgende callback functies om de resultaten van de vergunningsvraag te behandelen:

Clientloze API

Generic AccessEnabler Authorization Workflow generic-ae-authr-wf

Afmeldingsstroom logout

Wist tokens en andere gegevens verbonden aan de de machtigingsstroom van de huidige gebruiker.

AccessEnabled

Clientloze API

Begrijp AccessEnabler gedrag ae-behavior

Alle API-aanroepen van AccessEnabler zijn asynchroon (met één uitzondering vermeld in de API-referenties). U kunt API een willekeurig aantal tijden roepen, nochtans is er geen sterke garantie dat de acties die door de vraag teweeggebracht worden in de zelfde orde zullen worden voltooid dat de vraag werd gemaakt. (Een uitzondering hierop is de huidige runtime van de Flash Player; als u geen multi-threaded bent, worden aanroepen zeker do voltooid in de volgorde waarin ze worden aangeroepen.)

Om tussen reacties te onderscheiden, en reacties met vraag te kunnen paren, alle callbacks echo terug hun inputparameters. Dit omvat setToken() entokenRequestFailed(), die uiteindelijk door checkAuthorization(). (Voor checkAuthorization() callbacks, wordt de gebruikte bron teruggekaatst.) Gebruikend uit deze eigenschap, kunt u onderscheiden welke reactie beantwoordt aan welke vraag. Als u deze functie wilt gebruiken, kunt u iets als volgt coderen:

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

Veelgestelde vragen over gedrag AE ae-beh-faq

Vraag. Wat gebeurt als ik een tweede vraag AccessEnabler maak alvorens de eerste vraag eindigt?

De eerste vraag blijft uitvoeren aangezien de tweede vraag (asynchrone mededelingen) uitvoert.

Vraag. Is er een maximumaantal gelijktijdige vraag die AccessEnabler kan steunen?

Geen grens wordt uitdrukkelijk geplaatst in de code AccessEnabler, zodat bent u beperkt slechts door uw beschikbare systeemmiddelen, evenals door de capaciteit van MVPD.