Cookbook de integração do Amazon FireOS (herdado) amazon-fireos-integration-cookbook

Crie suas funções de retorno de chamada:

• setRequestorComplete()

  • Acionado por setRequestor(), retorna êxito ou falha. Success indica que você pode continuar com chamadas de direito.

• displayProviderDialog(mvpds)

  • Disparado por getAuthentication() somente se o usuário não tiver selecionado um provedor (MVPD) e ainda não estiver autenticado. O parâmetro mvpds é uma matriz de provedores disponíveis para o usuário.

• "setAuthenticationStatus(status, motivo)"

  • Disparado por checkAuthentication() toda vez. Disparado por getAuthentication() somente se o usuário já estiver autenticado e tiver selecionado um provedor.

  • O status retornado é autenticado ou não é autenticado, o motivo descreve uma falha de autenticação ou uma ação de logout.

• navigateToUrl(url)

  • Ignorado no AmazonFireOS SDK, o método é usado em plataformas Android onde é acionado por getAuthentication() depois que o usuário seleciona um MVPD. O parâmetro url fornece o local da página de logon do MVPD.

• "sendTrackingData(event, data)"

  • Disparado por checkAuthentication(), getAuthentication(), checkAuthorization(), getAuthorization(), setSelectedProvider().
    O parâmetro event indica qual evento de direito ocorreu; o parâmetro data é uma lista de valores relacionados ao evento.

• setToken(token, resource)

  • Acionado por checkAuthorization() e getAuthorization() após uma autorização bem-sucedida para exibir um recurso.
  • O parâmetro token é o token de mídia de vida curta;o parâmetro resource é o conteúdo que o usuário está autorizado a exibir.

• "tokenRequestFailed(resource, code, description)"

  • Acionado por checkAuthorization() e getAuthorization() após uma autorização sem êxito.
  • O parâmetro resource é o conteúdo que o usuário estava tentando exibir; o parâmetro code é o código de erro que indica que tipo de falha ocorreu; o parâmetro description descreve o erro associado ao código de erro.

• seletedProvider(mvpd)

  • Disparado por getSelectedProvider().
  • O parâmetro mvpd fornece informações sobre o provedor selecionado pelo usuário.

• setMetadataStatus(metadados, chave, argumentos)

  • Acionado por getMetadata().
  • O parâmetro metadata fornece os dados específicos solicitados; o parâmetro key é a chave usada na solicitação getMetadata(); e o parâmetro arguments é o mesmo dicionário passado para getMetadata().

• "preauthorizedResources(resources)"

  • Disparado por checkPreauthorizedResources().
  • O parâmetro authorizedResources apresenta os recursos que o usuário está autorizado a exibir.

Inicie o aplicativo de nível superior.

Iniciar a autenticação do Adobe Pass.

1. Chame getInstance para criar uma única instância da Autenticação Adobe Pass AccessEnabler.

   • Dependência: Biblioteca FireOS da Amazon Nativa de Autenticação do Adobe Pass (AccessEnabler)

2. Chame setRequestor() para estabelecer a identificação do Programador; transmita no requestorID do Programador e (opcionalmente) uma matriz de pontos de extremidade de Autenticação Adobe Pass.

   • Dependência: RequestorID de Autenticação Adobe Pass Válido (trabalhe com seu Gerente de Conta de Autenticação Adobe Pass para organizar isso.)

   • Acionadores: retorno de chamada setRequestorComplete()

Nenhuma solicitação de direito pode ser concluída até que a identidade do solicitante seja totalmente estabelecida. Isso significa que, enquanto setRequestor() ainda estiver em execução, todas as solicitações de direitos subsequentes (por exemplo, checkAuthentication()) serão bloqueadas.

Você tem duas opções de implementação: depois que as informações de identificação do solicitante são enviadas ao servidor de backend, a camada de aplicativo da interface do usuário pode escolher uma das duas abordagens a seguir:

1. Aguarde o acionamento do retorno de chamada setRequestorComplete() (parte do delegado AccessEnabler). Essa opção fornece a maior certeza de que setRequestor() foi concluído, portanto, ela é recomendada para a maioria das implementações.
2. Continue sem aguardar o acionamento do retorno de chamada setRequestorComplete() e comece a emitir solicitações de direito. Essas chamadas (checkAuthentication, checkAuthorization, getAuthentication, getAuthorization, checkPreauthorizedResource, getMetadata, logout) são enfileiradas pela biblioteca AccessEnabler, que fará as chamadas de rede reais após setRequestor(). Ocasionalmente, essa opção pode ser interrompida se, por exemplo, a conexão de rede estiver instável.

Chame checkAuthentication() para verificar uma autenticação existente sem iniciar o fluxo de Autenticação completo. Se essa chamada for bem-sucedida, você poderá prosseguir diretamente para o Fluxo de autorização. Caso contrário, prossiga para o Fluxo de autenticação.

Chame getAuthentication() para iniciar o fluxo de autenticação ou obter a confirmação de que o usuário já está autenticado.

Acionadores:

• O retorno de chamada setAuthenticationStatus(), se o usuário já estiver autenticado. Nesse caso, prossiga diretamente para o Fluxo de Autorização.
• O retorno de chamada displayProviderDialog(), se o usuário ainda não estiver autenticado.

Apresentar ao usuário a lista de provedores enviada para displayProviderDialog().

Depois que o usuário selecionar um provedor, um WebView abrirá a página do provedor para que o usuário faça logon

Após um logon bem-sucedido do usuário, o WebView será fechado.

chame getAuthenticationToken(),, que instrui o AccessEnabler a recuperar o token de autenticação do servidor back-end.

[Opcional] Chame checkPreauthorizedResources(resources) para verificar quais recursos o usuário está autorizado a visualizar. O parâmetro resources é uma matriz de recursos protegidos associada ao token de autenticação do usuário.

Acionadores: Retorno de chamada de preAuthorizedResources()
Ponto de execução: após a conclusão do fluxo de autenticação

Se a autenticação tiver sido bem-sucedida, prossiga para o Fluxo de autorização.

Chame getAuthorization() para iniciar o fluxo de autorização.

Dependência: ResourceID(s) válido(s) acordado(s) com a(s) MVPD(s).

Observação: ResourceIDs devem ser os mesmos usados em qualquer outro dispositivo ou plataforma e serão os mesmos em MVPDs.

Validar autenticação e autorização.

• Se a chamada getAuthorization() tiver êxito: o usuário tem tokens AuthN e AuthZ válidos (o usuário é autenticado e autorizado a assistir à mídia solicitada).

• Se getAuthorization() falhar: examine a exceção lançada para determinar seu tipo (AuthN, AuthZ ou algo mais):

  • Se foi um erro de autenticação (AuthN), reinicie o fluxo de autenticação.
  • Se foi um erro de autorização (AuthZ), o usuário não está autorizado a assistir à mídia solicitada, e algum tipo de mensagem de erro deve ser exibido para o usuário.
  • Se houver algum outro tipo de erro (erro de conexão, erro de rede etc.), exiba uma mensagem de erro apropriada para o usuário.

Valide o token de mídia curta.

Use a biblioteca Verificador de Token de Mídia de Autenticação da Adobe Pass para verificar o token de mídia de vida curta retornado da chamada getAuthorization() acima:

• Se a validação for bem-sucedida: Reproduza a mídia solicitada para o usuário.
• Se a validação falhar: O token AuthZ era inválido, a solicitação de mídia deve ser recusada e uma mensagem de erro deve ser exibida ao usuário.

Retorne ao fluxo normal do aplicativo.

O usuário seleciona a mídia a ser exibida.

A mídia está protegida? Seu aplicativo verifica se a mídia selecionada está protegida:

• Se a mídia selecionada estiver protegida, o aplicativo iniciará o Fluxo de Autorização acima.
• Se a mídia selecionada não estiver protegida, reproduza a mídia para o usuário.

Ligue para logout() para desconectar o usuário. O AccessEnabler limpa todos os valores e tokens em cache obtidos pelo usuário para o MVPD atual em todos os solicitantes que compartilham o logon por meio do Logon único. Depois de limpar o cache, o AccessEnabler faz uma chamada de servidor para limpar as sessões do lado do servidor. Como a chamada do servidor pode resultar em um redirecionamento SAML para o IdP (isso permite a limpeza da sessão no lado do IdP), essa chamada deve seguir todos os redirecionamentos. Por esse motivo, essa chamada será tratada em um controle WebView, invisível para o usuário.

Observação: o fluxo de logout difere do fluxo de autenticação na medida em que o usuário não precisa interagir com o WebView de nenhuma maneira. Assim, é possível (e recomendado) tornar o controle do WebView invisível (ou seja: oculto) durante o processo de logout.