Flujo de asignación de derechos del programador prog-entitlement-flow

Información general overview

En este documento se describe el flujo de derechos básico desde la perspectiva del programador. Para obtener información sobre características y casos de uso que van más allá de la integración básica de TVE que se trata aquí, consulte Casos de uso del programador.

La autenticación de Adobe Pass media el flujo de asignación de derechos entre los programadores y las MVPD al proporcionar interfaces seguras y coherentes para ambas partes. Del lado del programador, la autenticación de Adobe Pass proporciona dos tipos generales de interfaz de asignación de derechos:

Además de la descripción general neutra para la plataforma que se presenta aquí, hay una descripción general específica de la API sin cliente aquí: Documentación de la API sin cliente. AccessEnabler se ejecuta de forma nativa en plataformas compatibles (AS/JS en la web, Objective-C en iOS y Java en Android). Las API de AccessEnabler son coherentes en todas las plataformas admitidas. Todas las plataformas que no admiten AccessEnabler utilizan la misma API sin cliente.

Para ambos tipos de interfaz, la autenticación de Adobe Pass media de forma segura el flujo de asignación de derechos entre la aplicación del programador y la MVPD del usuario:

Figura: Ecosistema de autenticación de Adobe Pass

Flujo de derecho entitlement-flow

Hay cuatro subflujos distintos que constituyen la asignación básica de derechos
flujo:

En la visita inicial de un usuario al sitio de un programador, el flujo de derechos se ejecuta en el orden anterior. Sin embargo, en visitas posteriores, dependiendo de si los tokens de autenticación y autorización han caducado o no, o según las políticas de visualización, un usuario solo puede pasar por uno o dos de los subflujos.

Flujo de inicio startup

Establece la identidad del programador y el dispositivo, realiza tareas de inicialización. Esto es un requisito previo para todas las llamadas de derechos subsiguientes.

Habilitador de acceso

API sin cliente

Flujo de autenticación authentication

La autenticación correcta genera un token de AuthN vinculado al dispositivo y al solicitante. La autenticación correcta es un requisito previo para la autorización.

Habilitador de acceso

API sin cliente

Un token de AuthN se considera válido si se cumplen los dos puntos siguientes:

Flujo de trabajo de autenticación inicial de Generic AccessEnabler generic-ae-initial-authn-flow

Flujo de autorización authorization

La autorización es un requisito previo para ver contenido protegido. La autorización correcta genera un token de AuthZ, junto con un token de medios de corta duración que se proporciona a la aplicación del programador por motivos de seguridad. Tenga en cuenta que, para admitir el flujo de trabajo de autorización, debe haber realizado previamente la configuración del solicitante necesaria y haber integrado el Comprobador de token de medios. Una vez completados, puede iniciar la autorización.

La aplicación inicia la autorización cuando un usuario solicita acceso a un recurso protegido. Se pasa un ID de recurso que especifica el recurso solicitado (por ejemplo, un canal, un episodio, etc.). La aplicación comprueba primero si hay un token de autenticación almacenado. Si no se encuentra ninguna, se inicia el proceso de autenticación.

Habilitador de acceso

Proporcione las siguientes funciones de llamada de retorno para controlar los resultados de
la llamada de autorización:

API sin cliente

Flujo de trabajo de autorización de Generic AccessEnabler generic-ae-authr-wf

Flujo de desconexión logout

Borra los tokens y otros datos asociados con el flujo de derechos del usuario actual.

Habilitador de acceso

API sin cliente

Comprender el comportamiento de AccessEnabler ae-behavior

Todas las llamadas a la API de AccessEnabler son asincrónicas (con una excepción, indicada en las referencias de la API). Puede llamar a una API un número arbitrario de veces, pero no hay una garantía sólida de que las acciones se hayan activado
por las llamadas se completarán en el mismo orden en que se realizaron las llamadas. (Una excepción a esto es el tiempo de ejecución del Flash Player actual; al no ser de subprocesos múltiples, se asegurará de que las llamadas do se completen en el orden
se llaman.)

Para distinguir entre respuestas y poder emparejar respuestas con llamadas, todas las llamadas de retorno repiten sus parámetros de entrada. Esto incluye setToken() y tokenRequestFailed(), que se desencadenaron finalmente por checkAuthorization(). (Para las llamadas de retorno de checkAuthorization(), el recurso usado se devuelve). Aprovechando esta función, puede distinguir qué respuesta corresponde a cada llamada. Para utilizar esta función, puede codificar algo similar a lo siguiente:

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

Preguntas frecuentes sobre comportamiento de AEM ae-beh-faq

Pregunta. ¿Qué sucede si realizo una segunda llamada a AccessEnabler antes de que finalice la primera llamada?

La primera llamada sigue ejecutándose mientras se ejecuta la segunda llamada (comunicaciones asincrónicas).

Pregunta. ¿Hay un número máximo de llamadas simultáneas que AccessEnabler puede admitir?

No se ha establecido ningún límite explícitamente en el código AccessEnabler, por lo que sólo está limitado por los recursos de sistema disponibles, así como por la capacidad de la MVPD.