Flusso adesione programmatore prog-entitlement-flow

Panoramica overview

Questo documento descrive il flusso di adesione di base dal punto di vista del programmatore. Per informazioni sulle funzioni e sui casi d’uso oltre l’integrazione TVE di base trattata qui, consulta Casi di utilizzo dei programmatori.

L'autenticazione Adobe Pass media il flusso di adesione tra Programmatori e MVPD fornendo interfacce sicure e coerenti per entrambe le parti. Dal lato del programmatore, Adobe Pass Authentication fornisce due tipi generali di interfaccia di adesione:

Oltre alla panoramica indipendente dalla piattaforma presentata qui, è disponibile una panoramica specifica per le API senza client qui: documentazione API senza client. AccessEnabler viene eseguito in modalità nativa sulle piattaforme supportate (AS/JS sul Web, Objective-C su iOS e Java su Android). Le API di AccessEnabler sono coerenti tra le piattaforme supportate. Tutte le piattaforme che non supportano AccessEnabler utilizzano la stessa API senza client.

Per entrambi i tipi di interfaccia, l’autenticazione Adobe Pass media in modo sicuro il flusso di adesione tra l’app del programmatore e l’MVPD dell’utente:

Figura: Ecosistema di autenticazione di Adobe Pass

Flusso diritto entitlement-flow

Esistono quattro flussi secondari distinti che costituiscono il flusso di adesione di base:

Durante la visita iniziale di un utente al sito di un programmatore, il flusso di adesione procede nell’ordine indicato sopra. Tuttavia, nelle visite successive, a seconda che i token di autenticazione e autorizzazione siano scaduti o meno, o a seconda dei criteri di visualizzazione, un utente potrebbe passare attraverso solo uno o due dei flussi secondari.

Flusso di avvio startup

Stabilisce l'identità del programmatore e del dispositivo, esegue le attività di inizializzazione. Questo è un prerequisito per tutte le chiamate di adesione successive.

AccessEnabler

API senza client

Flusso di autenticazione authentication

Se l'autenticazione ha esito positivo, viene generato un token AuthN associato al dispositivo e al richiedente. La corretta autenticazione è un prerequisito per l’autorizzazione.

AccessEnabler

API senza client

Un token AuthN è considerato valido se sono soddisfatte le due condizioni seguenti:

Flusso di lavoro di autenticazione iniziale di AccessEnabler generico generic-ae-initial-authn-flow

Flusso di autorizzazione authorization

L’autorizzazione è un prerequisito per la visualizzazione di contenuti protetti. Se l’autorizzazione è andata a buon fine, viene generato un token AuthZ insieme a un token multimediale di breve durata fornito all’app del programmatore a scopo di sicurezza. Tieni presente che, per supportare il flusso di lavoro di autorizzazione, è necessario aver precedentemente eseguito la configurazione del richiedente necessaria e aver integrato Media Token Verifier. Una volta completati, puoi avviare l’autorizzazione.

L’app avvia l’autorizzazione quando un utente richiede l’accesso a una risorsa protetta. Trasmetti un ID risorsa specificando la risorsa richiesta (ad esempio, un canale, un episodio, ecc.). L'app verifica innanzitutto la presenza di un token di autenticazione archiviato. Se non ne viene trovata una, viene avviato il processo di autenticazione.

AccessEnabler

Per gestire i risultati della chiamata di autorizzazione, fornisci le seguenti funzioni di callback:

API senza client

Flusso di lavoro di autorizzazione di AccessEnabler generico generic-ae-authr-wf

Flusso di disconnessione logout

Cancella i token e gli altri dati associati al flusso di adesione dell'utente corrente.

AccessEnabler

API senza client

Comprendere il comportamento di AccessEnabler ae-behavior

Tutte le chiamate API di AccessEnabler sono asincrone (con una eccezione, indicata nei riferimenti API). È possibile chiamare un’API un numero arbitrario di volte, tuttavia non esiste una solida garanzia che le azioni attivate dalle chiamate vengano completate nello stesso ordine in cui sono state effettuate le chiamate. (Fa eccezione il runtime di Flash Player corrente; non essendo multi-threaded, garantirà che le chiamate fare complete nell'ordine in cui vengono chiamate.)

Per distinguere le risposte ed essere in grado di associare le risposte alle chiamate, tutti i callback eseguono l'echo dei parametri di input. Ciò include setToken() etokenRequestFailed(), che vengono attivati in ultima analisi da checkAuthorization(). (Per checkAuthorization() callback, la risorsa utilizzata viene ripetuta). Sfruttando questa funzione, puoi distinguere quale risposta corrisponde a quale chiamata. Per utilizzare questa funzione è possibile codificare un codice simile al seguente:

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

Domande frequenti sul comportamento AE ae-beh-faq

Domanda. Cosa succede se effettuo una seconda chiamata di AccessEnabler prima del termine della prima chiamata?

La prima chiamata continua a essere eseguita durante l’esecuzione della seconda chiamata (comunicazioni asincrone).

Domanda. Esiste un numero massimo di chiamate simultanee supportate da AccessEnabler?

Poiché nel codice AccessEnabler non viene impostato esplicitamente alcun limite, l'utente è limitato solo dalle risorse di sistema disponibili e dalla capacità di MVPD.