Guía de API de REST V2 (servidor a servidor) rest-api-v2-cookbook-server-to-server

Comuníquese con el servicio de Adobe Pass en nombre de la aplicación de streaming.

Recopile y pase un identificador de dispositivo único para el dispositivo de transmisión según lo requerido por el encabezado AP-Device-Identifier.

Recopile y pase información precisa del dispositivo de transmisión, incluido el puerto de origen y los detalles específicos del dispositivo, según lo requerido por el encabezado X-Device-Info.

Recopile y pase la dirección IP del dispositivo de streaming según lo requerido por el encabezado X-Forwarded-For.

Almacene de forma segura parámetros como ID de dispositivo, ID de cliente y secreto de cliente en la aplicación de streaming o en el servicio de programador.

Formatee y envíe datos de conformidad con MVPD y aplicaciones integradas, incluidas la IP del dispositivo, el puerto de origen, la información específica del dispositivo, los MRSS y los identificadores opcionales como ECID.

Mantenga y administre de forma segura los certificados compartidos con Adobe para la transmisión cifrada de metadatos de usuarios.

Respete la validez del perfil de autenticación y de la decisión de autorización al almacenar en caché, asegurándose de que los estados de autenticación y autorización se invaliden cuando se notifiquen.

Devuelva las decisiones de autorización e instrucciones relevantes a la aplicación de streaming.

El servicio Adobe Pass funciona en varios centros de datos distribuidos geográficamente en todo Estados Unidos para optimizar el rendimiento y minimizar la latencia.

• El servicio de programación debe adoptar una estrategia de infraestructura similar, lo que garantiza tiempos de respuesta de baja latencia de Adobe Pass.

El programador debe proporcionar el rango de IP pública de su entorno de producción.

• Estas IP se añadirán a una lista de permitidos dentro de la infraestructura de Adobe Pass.

El servicio de programador debe limitar el almacenamiento en caché de DNS a un máximo de 30 segundos para permitir el redireccionamiento dinámico en caso de que Adobe necesite redirigir el tráfico debido a que un centro de datos deja de estar disponible.

Debe permitir versiones de prueba antes de la implementación en producción.

Desde el punto de vista operativo, debería ser similar a la producción, lo que permitiría realizar pruebas realistas.

Lo ideal es que el entorno de ensayo se conecte a los entornos de prueba de Adobe Pass para lo siguiente:

• Permita que los programadores realicen pruebas con la infraestructura de Adobe.

• Habilite Adobe para ayudarle con las pruebas y la resolución de problemas cuando sea necesario.

Recuperar credenciales de cliente: el servicio de programación recupera las credenciales de cliente llamando al extremo /o/client/register.

• El servicio de programador o la aplicación de programador deben almacenar las credenciales del cliente y utilizarlas indefinidamente cuando necesite recuperar un token de acceso.

Recuperar token de acceso: el servicio de programador recupera el token de acceso llamando al extremo /o/client/token.

• El servicio de programador o la aplicación de programador deben almacenar y utilizar el token de acceso hasta que caduque y, a continuación, descartarlo y obtener uno nuevo.

Recuperar perfiles: El servicio de programación comprueba los perfiles existentes en nombre de la aplicación de streaming llamando al extremo /api/v2/{serviceProvider}/profiles.

Escenario 1: Hay perfiles existentes, el Servicio de programador puede continuar con la Fase de preautorización o Fase de autorización.

Escenario 2: No existen perfiles, el Servicio de programador puede continuar con el siguiente paso para Autenticar al usuario.

Escenario 3: No existen perfiles, el Servicio de programador puede proceder a proporcionar al usuario acceso temporal a través de la característica TempPass.

• Este escenario está fuera del ámbito de este documento. Consulte la documentación de Flujos de acceso temporales para obtener más información.

Recuperar configuración: El servicio de programación recupera la lista de MVPD disponibles llamando al extremo /api/v2/{serviceProvider}/configuration.

• El servicio de programación puede implementar un mecanismo de filtrado personalizado para refinar la lista de MVPD de la respuesta de configuración, de modo que la aplicación de streaming muestre solo los proveedores deseados mientras oculta otros (por ejemplo, MVPD en desarrollo, MVPD de prueba, TempPass). Esto garantiza que los usuarios tengan una selección revisada al elegir su proveedor de TV.

Crear sesión de autenticación: El servicio Programador inicia una sesión de autenticación llamando al extremo /api/v2/{serviceProvider}/session.

• El servicio de programador debe devolver code y url a la aplicación de streaming.

Escenario 1: La aplicación de streaming puede abrir un explorador o una vista web, por lo que debe cargar la autenticación url.

• El usuario envía su nombre de usuario y contraseña en la página de inicio de sesión de MVPD. Tras la autenticación correcta, la redirección final muestra una página de éxito.

Escenario 2: La aplicación de streaming no puede abrir un explorador, por lo que debe mostrar la autenticación code. Se requiere una aplicación web independiente para solicitar al usuario que introduzca code, construya la autenticación url y abra: /api/v2/authenticate/{serviceProvider}/{code}.

• El usuario envía su nombre de usuario y contraseña en la página de inicio de sesión de MVPD. Tras la autenticación correcta, la redirección final muestra una página de éxito.

Recuperar perfil para código específico: El servicio de programador debe implementar un mecanismo de sondeo usando code para comprobar si el perfil se generó correctamente y se guardó llamando al extremo /api/v2/{serviceProvider}/profiles/code/{code}.

• El servicio de programador debe iniciar el mecanismo de sondeo en las siguientes condiciones:

  • Autenticación realizada en la aplicación principal (pantalla): El servicio de programador debe comenzar a sondear cuando el usuario llegue a la página de destino final, después de que el componente del explorador cargue la dirección URL especificada para el parámetro redirectUrl en la solicitud de extremo de Sessions.

  • Autenticación realizada en una aplicación secundaria (pantalla): La aplicación del servicio de programador debe comenzar a sondear en cuanto el usuario inicie el proceso de autenticación, justo después de recibir la respuesta del extremo Sessions y mostrar el código de autenticación al usuario.

• El servicio de programador debe detener el mecanismo de sondeo en las siguientes condiciones:

  • Autenticación correcta: La información de perfil del usuario se ha recuperado correctamente, lo que confirma su estado de autenticación. En este punto, ya no es necesario el sondeo.

  • Sesión de autenticación y caducidad del código: La sesión de autenticación y el código caducan, tal como indica la marca de tiempo notAfter (por ejemplo, 30 minutos) en la respuesta de extremo Sessions. Si esto sucede, el usuario debe reiniciar el proceso de autenticación y el sondeo con el código de autenticación anterior debe detenerse inmediatamente.

  • Nuevo código de autenticación generado: Si el usuario solicita un nuevo código de autenticación en el dispositivo principal (pantalla), la sesión existente ya no es válida y el sondeo con el código de autenticación anterior debe detenerse inmediatamente.

• El servicio de programación debe configurar la frecuencia del mecanismo de sondeo en las siguientes condiciones:

  • Autenticación realizada en la aplicación principal (pantalla): El servicio de programador debe sondear cada 3-5 segundos o más.

  • Autenticación realizada en una aplicación secundaria (pantalla): El servicio de programador debe sondear cada 3-5 segundos o más.

• El servicio Programador debe almacenar en caché partes de la información de perfil del usuario en un almacenamiento persistente para evitar solicitudes innecesarias y mejorar la experiencia del usuario.

Recuperar decisiones de preautorización: El servicio Programador recupera decisiones de preautorización para una lista de recursos llamando al extremo /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd}.

• El servicio de programador debe pasar la lista de decisiones de permiso y denegar la preautorización a la aplicación de streaming.

• El servicio Programador no es necesario para almacenar las decisiones de preautorización en el almacenamiento persistente. Sin embargo, se recomienda almacenar en caché las decisiones de permiso en la memoria para mejorar la experiencia del usuario. Esto ayuda a evitar llamadas innecesarias a recursos que ya se han preautorizado, lo que reduce la latencia y mejora el rendimiento.

• El servicio de programación puede determinar el motivo de una decisión de autorización previa denegada inspeccionando el código de error y el mensaje incluidos en la respuesta del extremo de autorización previa de Decisions. Estos detalles proporcionan a insight el motivo específico por el que se denegó la solicitud de preautorización, lo que ayuda a informar a la experiencia del usuario o al déclencheur de cualquier tratamiento necesario en la aplicación. Asegúrese de que cualquier mecanismo de reintento implementado para recuperar decisiones de preautorización no genere un bucle interminable si se deniega la decisión de preautorización. Considere la posibilidad de limitar los reintentos a un número razonable y administrar las denegaciones correctamente mostrando comentarios claros al usuario.

• El servicio de programación puede obtener una decisión de preautorización para un número limitado de recursos en una sola solicitud de API, normalmente hasta 5, debido a las condiciones impuestas por las MVPD. Este número máximo de recursos se puede ver y cambiar después de ponerse de acuerdo con las MVPD a través del TVE Dashboard de Adobe Pass por uno de los administradores de la organización o por un representante de autenticación de Adobe Pass que actúe en su nombre.

Recuperar decisión de autorización: El servicio de programador recupera la decisión de autorización para un recurso específico pasado por la aplicación de transmisión llamando al extremo /api/v2/{serviceProvider}/decision/authorize/{mvpd}.

• El servicio Programador no es necesario para almacenar las decisiones de autorización en almacenamiento persistente.

• El servicio de programador puede determinar el motivo de una decisión de autorización denegada inspeccionando el código de error y el mensaje incluidos en la respuesta del extremo de autorización de decisiones. Estos detalles proporcionan a insight la razón específica por la que se denegó la solicitud de autorización, lo que ayuda a informar a la experiencia del usuario o al déclencheur de cualquier manejo necesario en la aplicación de streaming. Asegúrese de que cualquier mecanismo de reintento implementado para recuperar decisiones de autorización no genere un bucle interminable si se deniega la decisión de autorización. Considere la posibilidad de limitar los reintentos a un número razonable y administrar las denegaciones correctamente mostrando comentarios claros al usuario.

• El Servicio de programador puede evaluar otras reglas comerciales y devolver una decisión de autorización adecuada a la Aplicación de streaming.

• El servicio Programador no es necesario para actualizar un token de medios caducado mientras el flujo se está reproduciendo activamente. Si el token de medios caduca durante la reproducción, se debe permitir que el flujo continúe ininterrumpidamente. Sin embargo, el cliente debe solicitar una nueva decisión de autorización y obtener un nuevo token de medios la próxima vez que el usuario intente reproducir un recurso.

• El servicio de programación puede obtener una decisión de autorización para un número limitado de recursos en una sola solicitud de API, normalmente hasta 1, debido a condiciones impuestas por MVPD.

Iniciar el cierre de sesión de Adobe Pass: el servicio de programación inicia el flujo de cierre de sesión como lo solicita la aplicación de streaming llamando al extremo /api/v2/{serviceProvider}/logout/{mvpd}.

• El Servicio de programador puede limpiar cualquier información que almacene sobre el usuario autenticado.

• El servicio de programador debe seguir las instrucciones proporcionadas en los atributos actionName y actionType de la respuesta de extremo de cierre de sesión para garantizar que el proceso de cierre de sesión se complete correctamente.

  • Si el atributo actionType de la respuesta se establece en "interactivo", el servicio de programador debe devolver el valor del atributo url a la aplicación de streaming.

    • Escenario 1: La aplicación de streaming puede abrir un explorador o una vista web, por lo que debe cargar el cierre de sesión url.

    • Escenario 2: La aplicación de streaming no puede abrir un explorador, por lo que el proceso de cierre de sesión se puede detener porque la sesión de MVPD no persistió en la memoria caché de un explorador de Dispositivo de streaming.