O fluxo de direitos do programador prog-entitlement-flow

Visão geral overview

Este documento descreve o fluxo de direitos básicos da perspectiva do programador. Para obter informações sobre recursos e casos de uso além da integração básica da TVE abordada aqui, consulte Casos de uso de programadores.

A Autenticação Adobe Pass é a mediadora do fluxo de direitos entre os Programadores e os MVPDs, fornecendo interfaces seguras e consistentes para ambas as partes. Do lado do programador, a Autenticação Adobe Pass fornece dois tipos gerais de interface de direito:

Além da visão geral neutra em relação à plataforma apresentada aqui, há uma visão geral específica da API sem cliente aqui: Documentação da API sem cliente. O AccessEnabler é executado nativamente nas plataformas compatíveis (AS/JS na Web, Objetive-C no iOS e Java no Android). As APIs do AccessEnabler são consistentes em todas as plataformas compatíveis. Todas as plataformas que não oferecem suporte ao AccessEnabler usam a mesma API sem clientes.

Para ambos os tipos de interface, a Autenticação do Adobe Pass é a mediadora segura do fluxo de direitos entre o aplicativo do Programador e o MVPD do usuário:

Figura: Ecossistema De Autenticação Do Adobe Pass

Fluxo de direitos entitlement-flow

Existem quatro sub-fluxos distintos que constituem o direito de base
fluxo:

Na visita inicial de um usuário ao site de um Programador, o fluxo de direitos continua na ordem acima. No entanto, em visitas subsequentes, dependendo de os tokens de autenticação e autorização terem expirado ou não, ou dependendo das políticas de exibição, um usuário só pode passar por um ou dois sub-fluxos.

Fluxo de inicialização startup

Estabelece a identidade do Programador e do dispositivo e executa tarefas de inicialização. Isso é um pré-requisito para todas as chamadas de direito subsequentes.

AccessEnabler

API sem cliente

Fluxo de autenticação authentication

Autenticação bem-sucedida gera um token de Autenticação vinculado ao dispositivo e ao solicitante. A autenticação bem-sucedida é um pré-requisito para a Autorização.

AccessEnabler

API sem cliente

Um token de autenticação será considerado válido se os dois pontos a seguir forem verdadeiros:

Fluxo de trabalho de autenticação inicial genérico do AccessEnabler generic-ae-initial-authn-flow

Fluxo de autorização authorization

A autorização é um pré-requisito para a exibição de conteúdo protegido. Uma autorização bem-sucedida gera um token AuthZ, juntamente com um token de mídia de curta duração, fornecido ao aplicativo do programador para fins de segurança. Observe que, para oferecer suporte ao fluxo de trabalho de autorização, você deve ter executado anteriormente a configuração necessária do solicitante e integrado o Verificador de Token de Mídia. Com elas concluídas, é possível iniciar a autorização.

Seu aplicativo inicia a autorização quando um usuário solicita acesso a um recurso protegido. Você passa uma ID de recurso especificando o recurso solicitado (por exemplo, um canal, episódio etc.). Primeiro, seu aplicativo verifica se há um token de autenticação armazenado. Se nenhum for encontrado, você iniciará o processo de autenticação.

AccessEnabler

Você fornece as seguintes funções de retorno de chamada para lidar com os resultados de
a chamada de autorização:

API sem cliente

Fluxo de trabalho de autorização genérico do AccessEnabler generic-ae-authr-wf

Fluxo de logout logout

Limpa tokens e outros dados associados ao fluxo de direitos do usuário atual.

AccessEnabler

API sem cliente

Entender o comportamento do AccessEnabler ae-behavior

Todas as chamadas de API do AccessEnabler são assíncronas (com uma exceção, anotada nas referências da API). Você pode chamar uma API um número arbitrário de vezes, no entanto, não há uma garantia forte de que as ações acionadas
pelas chamadas serão concluídas na mesma ordem em que as chamadas foram feitas. (Uma exceção a esta regra é o tempo de execução do Flash Player atual; não sendo multi-segmentado, ele irá garantir que as chamadas do sejam concluídas na ordem
eles são chamados.)

Para distinguir entre respostas e poder emparelhar respostas com chamadas, todos os retornos de chamada ecoam seus parâmetros de entrada. Isso inclui setToken() e tokenRequestFailed(), que são acionados por checkAuthorization(). (Para retornos de chamada checkAuthorization(), o recurso usado é ecoado de volta.) Aproveitando esse recurso, você pode distinguir qual resposta corresponde a qual chamada. Para usar esse recurso, você pode codificar algo como o seguinte:

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

Perguntas frequentes sobre comportamento do AEM ae-beh-faq

Pergunta. O que acontece se eu fizer uma segunda chamada AccessEnabler antes da conclusão da primeira chamada?

A primeira chamada continua a ser executada conforme a segunda chamada é executada (comunicações assíncronas).

Pergunta. Há um número máximo de chamadas simultâneas que o AccessEnabler pode suportar?

Nenhum limite é definido explicitamente no código AccessEnabler, portanto, você está limitado apenas pelos recursos de sistema disponíveis, bem como pela capacidade do MVPD.