Accesso e disconnessione senza aggiornamento

Documentazione Adobe Pass Autenticazione Adobe Pass

Ultimo aggiornamento: 14 dicembre 2024

Argomenti:
Autenticazione

NOTA

Il contenuto di questa pagina viene fornito solo a scopo informativo. L’utilizzo di questa API richiede una licenza corrente da Adobe. Non è consentito alcun uso non autorizzato.

IMPORTANTE

Assicurati di essere sempre informato sugli ultimi annunci di prodotto per l'autenticazione di Adobe Pass e sulle timeline di disattivazione aggregate nella pagina Annunci di prodotto.

Panoramica

Per le applicazioni web, è necessario tenere conto di alcuni possibili scenari diversi per l’autenticazione e la disconnessione degli utenti. Gli MVPD richiedono che gli utenti accedano alla pagina web di MVPD per autenticarsi, con i seguenti fattori aggiuntivi in gioco:

Alcuni MVPD richiedono un reindirizzamento completo dal sito alla pagina di accesso
Alcuni MVPD richiedono di aprire un iFrame sul sito per visualizzare la pagina di accesso di MVPD
Alcuni browser non gestiscono bene lo scenario iFrame, quindi per questi browser un’alternativa migliore è utilizzare una finestra popup invece dell’iFrame

Prima dell’autenticazione Adobe Pass 2.7, tutti questi scenari per l’autenticazione di un utente richiedevano un aggiornamento dell’intera pagina del programmatore.Per la versione 2.7 e successive, il team di autenticazione di Adobe Pass ha migliorato questi flussi in modo che l’utente non debba aggiornare la pagina dell’app durante l’accesso e la disconnessione.

Descrizione dettagliata

Iniziamo con un riepilogo dei flussi di autenticazione e disconnessione originali, quindi seguiamo questo con i flussi di autenticazione e disconnessione migliorati. Si noti che le prime quattro sezioni riguardano i normali MVPD (non-TempPass), mentre l'ultima descrive l'implementazione speciale che deve essere applicata per TempPass:

Flusso di autenticazione originale
Flusso di disconnessione originale
Flusso di autenticazione migliorato
Flusso di disconnessione migliorato
Flusso TempPass

Flussi di autenticazione/disconnessione originali

Autenticazione

I client web di Adobe Pass Authentication possono autenticarsi in due modi, a seconda dei requisiti degli MVPD:

Reindirizzamento a pagina intera - dopo che l'utente ha selezionato un provider (configurato con reindirizzamento a pagina intera) dal selettore MVPD sulla Il sito Web del programmatore setSelectedProvider(<mvpd>) viene richiamato in AccessEnabler e l'utente viene reindirizzato alla pagina di accesso di MVPD. Dopo che l'utente ha fornito credenziali valide, viene reindirizzato al sito Web del programmatore. AccessEnabler è inizializzato e il token di autenticazione viene recuperato dall'autenticazione di Adobe Pass durante setRequestor.
Finestra iFrame/Popup - Dopo che l'utente ha selezionato un provider (configurato con iFrame), setSelectedProvider(<mvpd>) viene richiamato in AccessEnabler. Questa azione attiverà il callback createIFrame(width, height), avvisando il programmatore di creare un iFrame (o pop-up - a seconda del browser/preferenze) con il nome "mvpdframe" e le dimensioni fornite. Dopo aver creato l’iFrame/popup, AccessEnabler carica la pagina di accesso di MVPD nell’iFrame/popup. L’utente fornisce credenziali valide e l’iFrame/popup viene reindirizzato all’autenticazione Adobe Pass, che restituisce uno snippet JS che chiude l’iFrame/popup e ricarica la pagina padre (sito web Programmatore). Analogamente al flusso 1, il token di autenticazione viene recuperato durante setRequestor.

Il callback displayProviderDialog (attivato da getAuthentication/getAuthorization) restituisce un elenco di MVPD e le relative impostazioni appropriate. La proprietà iFrameRequired di un MVPD consente al programmatore di sapere se deve attivare il flusso 1 o il flusso 2. Si noti che il programmatore è tenuto a intraprendere azioni aggiuntive (creazione di un iFrame/popup) solo per il flusso 2.

Annulla autenticazione

Inoltre, l’utente annulla esplicitamente il flusso di autenticazione chiudendo la pagina di accesso. Di seguito sono riportati gli scenari e la soluzione proposta ai programmatori:

Reindirizzamento a pagina intera - Quando la pagina di accesso viene chiusa, l'utente dovrà tornare al sito Web del programmatore e avviare l'intero flusso dall'inizio. In questo scenario non è richiesta alcuna azione esplicita da parte del programmatore.
iFrame - Si consiglia al programmatore di ospitare l'iFrame all'interno di un div (o componente simile dell'interfaccia utente) a cui è associato un pulsante Chiudi. Quando l'utente preme il pulsante Chiudi, il programmatore distrugge l'iFrame insieme all'interfaccia utente associata ed esegue setSelectedProvider(null). Questa chiamata consente ad AccessEnabler di cancellare il proprio stato interno e consente all'utente di avviare un flusso di autenticazione successivo. setAuthenticationStatus e sendTrackingData(AUTHENTICATION_DETECTION...) verranno attivati per segnalare un flusso di autenticazione non riuscito (sia su getAuthentication che su getAuthorization).
Popup - Alcuni browser non sono in grado di rilevare con precisione l'evento di chiusura della finestra, pertanto è necessario adottare un approccio diverso (a differenza del flusso iFrame riportato sopra). Adobe consiglia al programmatore di inizializzare un timer che verifichi periodicamente l'esistenza del popup di accesso. Se la finestra non esiste, il programmatore può essere sicuro che l'utente abbia annullato manualmente il flusso di accesso e che il programmatore possa continuare a chiamare setSelectedProvider(null). I callback attivati sono gli stessi del flusso 2 precedente.

Flusso di disconnessione originale

L'API di disconnessione di AccessEnabler cancella lo stato locale della libreria e carica l'URL di disconnessione di MVPD nella scheda/finestra corrente. Il browser passa all’endpoint di disconnessione di MVPD e al termine del processo, l’utente viene reindirizzato al sito web del programmatore. L'unica azione richiesta per conto dell'utente è premere il pulsante o il collegamento Logout e avviare il flusso; non è richiesta alcuna interazione dell'utente sull'endpoint logout di MVPD.

Autenticazione Originale / Flusso Di Disconnessione Con Aggiornamento Pagina

Autenticazione migliorata (senza aggiornamento)

NOTE

I flussi migliorati di accesso e disconnessione senza aggiornamento richiedono che il browser supporti le moderne tecnologie HTML5, tra cui la messaggistica web.

I flussi di autenticazione (accesso) e disconnessione descritti in precedenza forniscono un’esperienza utente simile ricaricando la pagina principale al termine di ogni flusso. La funzione corrente mira a migliorare l’esperienza utente fornendo un accesso e una disconnessione senza aggiornamento (in background). Il programmatore può abilitare/disabilitare l'accesso e la disconnessione in background passando due flag booleani (backgroundLogin e backgroundLogout) al parametro configInfo dell'API setRequestor. Per impostazione predefinita, l’accesso o la disconnessione in background sono disabilitati (in questo modo si garantisce la compatibilità con l’implementazione precedente).

Esempio:

    var configInfo = {
        callSetConfig: true,
        backgroundLogin: true,
        backgroundLogout: true
    };
    accessEnabler.setRequestor(REQUESTOR_ID, null, configInfo);

Autenticazione

I punti seguenti descrivono la transizione tra i flussi di autenticazione originali e i flussi migliorati:

Il reindirizzamento a pagina intera viene sostituito da una nuova scheda del browser in cui viene eseguito l’accesso a MVPD. Il programmatore deve creare una nuova scheda (tramite window.open) denominata mvpdwindow quando l'utente seleziona un MVPD (con iFrameRequired = false). Il programmatore esegue quindi setSelectedProvider(<mvpd>), consentendo ad AccessEnabler di caricare l'URL di accesso di MVPD nella nuova scheda. Dopo che l'utente avrà fornito credenziali valide, Adobe Pass Authentication chiuderà la scheda e invierà un window.postMessage al sito Web del programmatore che segnala ad AccessEnabler il completamento del flusso di autenticazione. Vengono attivati i seguenti callback:
- Se il flusso è stato avviato da getAuthentication: setAuthenticationStatus e sendTrackingData(AUTHENTICATION_DETECTION...) verranno attivati per segnalare un'autenticazione riuscita/non riuscita.
- Se il flusso è stato avviato da getAuthorization: setToken/tokenRequestFailed e sendTrackingData(AUTHORIZATION_DETECTION...) verranno attivati per segnalare un'autorizzazione riuscita/non riuscita.
Il flusso della finestra iFrame / popup rimane per lo più invariato, con la differenza che dopo che l'utente ha fornito credenziali valide, la pagina padre non verrà ricaricata. L'iFrame o il popup verrà chiuso automaticamente dopo l'accesso e window.postMessage verrà inviato alla pagina padre, notificando all'AccessEnabler il completamento del flusso. Vengono attivati gli stessi callback del flusso precedente, più il nuovo callback seguente:destroyIFrame. Il callback destroyIFrame consente al programmatore di rimuovere qualsiasi componente iFrame associato/ausiliario, ad esempio le decorazioni dell'interfaccia utente. L’esistenza di questo callback non era necessaria nel vecchio flusso di autenticazione perché al termine dell’accesso, l’autenticazione Adobe Pass ricaricava la pagina del programmatore, distruggendo tutti i componenti dell’interfaccia utente.

IMPORTANT

È necessario caricare l'iFrame di accesso MVPD o la finestra popup come figlio diretto della pagina che contiene l'istanza di AccessEnabler. Se l'iFrame o la finestra popup di accesso a MVPD è nidificata a due o più livelli sotto la pagina contenente l'istanza di AccessEnabler, il flusso potrebbe bloccarsi. Ad esempio, se disponi di un iFrame situato tra la pagina principale e l’iFrame di MVPD (Page => iFrame => MVPD iFrame), il flusso di accesso potrebbe non riuscire.

Annulla autenticazione

Di seguito sono riportati i flussi per annullare l’autenticazione:

Scheda Browser - Poiché la scheda è fondamentalmente una nuova finestra, l'acquisizione del relativo evento di chiusura presenta le stesse limitazioni illustrate nello scenario 3 dai flussi di autenticazione precedenti. Inoltre, l’approccio basato sul timer non è possibile in questo caso, perché non è possibile distinguere tra una scheda chiusa manualmente dall’utente e una scheda chiusa automaticamente alla fine del flusso di accesso. In questo caso, la soluzione prevede che AccessEnabler rimanga "invisibile all’utente" (non vengono attivati callback) quando l’utente annulla il flusso. Inoltre, il programmatore non è tenuto a intraprendere alcuna azione specifica. L'utente sarà in grado di avviare un altro flusso di autenticazione senza ricevere l'errore "Errore più richieste di autenticazione" (questo errore è stato disabilitato in AccessEnabler per l'accesso in background).
iFrame - Il programmatore può seguire l'approccio descritto nello scenario 2 dai vecchi flussi di autenticazione (creare un'interfaccia utente wrapper dall'iFrame e il pulsante Close associato che attiva setSelectedProvider(null)). Anche se questo approccio non è più un requisito importante (per l’accesso in background sono consentiti più flussi di autenticazione, come discusso nello scenario 1 di cui sopra), è ancora consigliato da Adobe.
Popup - È identico al flusso della scheda Browser qui sopra.

Flusso di disconnessione migliorato

Il nuovo flusso di logout verrà eseguito in un iFrame nascosto, eliminando in tal modo il reindirizzamento dell’intera pagina. Ciò è possibile perché l’utente non deve eseguire azioni specifiche sulla pagina di disconnessione di MVPD.

Una volta completato il flusso di logout, l’iFrame verrà reindirizzato a un endpoint di autenticazione Adobe Pass personalizzato. Verrà distribuito un frammento JS che esegue window.postMessage all'elemento padre, notificando all'AccessEnabler il completamento della disconnessione. Vengono attivati i seguenti callback: setAuthenticationStatus() e sendTrackingData(AUTHENTICATION_DETECTION ...), segnalando che l'utente non è più autenticato.

L’illustrazione seguente mostra il flusso senza aggiornamento che consente a un utente di accedere al proprio MVPD senza aggiornare la pagina principale dell’applicazione:

Flusso di autenticazione/disconnessione migliorato (senza aggiornamento)

Flusso TempPass

L’accesso senza aggiornamento segue un approccio diverso per gli MVPD di tipo TempPass.

Poiché il flusso TempPass richiede che una finestra venga creata automaticamente e chiusa senza esplicita interazione da parte dell’utente, potrebbe rappresentare un problema per alcuni browser (blocchi popup). AccessEnabler implementa quindi la fase di accesso dietro le quinte, senza richiedere un contenitore Web creato dal programmatore.

Di seguito sono riportati gli aspetti di cui il programmatore deve essere a conoscenza quando implementa TempPass per l’accesso e la disconnessione senza aggiornamento:

Prima di avviare l'autenticazione, è necessario creare l'iFrame o la finestra popup solo per gli MVPD non TempPass. Il programmatore può rilevare se un MVPD è TempPass o meno leggendo la proprietà tempPass dell'oggetto MVPD (restituita da setConfig() / displayProviderDialog()).
Il callback createIFrame() deve contenere un controllo per TempPass ed eseguire la relativa logica solo quando il MVPD non è TempPass.
Il callback destroyIFrame() deve contenere un controllo per TempPass ed eseguire la relativa logica solo quando il MVPD non è TempPass.
I callback setAuthenticationStatus() e sendTrackingData() vengono richiamati al termine dell'autenticazione (esattamente come nel flusso senza aggiornamento per i normali MVPD).

NOTE

Questo flusso è disponibile solo per TempPass senza aggiornamento. Per il flusso di aggiornamento, TempPass deve essere gestito esplicitamente (quando TempPass richiede iFrame / popup)

Nell'esempio di codice riportato di seguito viene illustrato come gestire una finestra di MVPD sul sito Web di un programmatore (sia per MVPD normali che per TempPass):

    var aeHostname = "https://entitlement.auth.adobe.com";
    var mvpdWindow = null;
    var mvpd = <mvpd_object_from_displayProviderDialog>;
    var useIframeLogin = <boolean_depending_on_browser_or_Programmer_preferences>;
    var backgroundLogin = <boolean_depending_on_Programmer_preferences>;

    // Do not create any windows for refreshless and temp pass
    if (!(backgroundLogin && mvpd.tempPass)) {
        if (backgroundLogin && !mvpd.popup) {
            mvpdWindow = window.open(aeHostname, "mvpdwindow");
        } else if (mvpd.popup && !useIframeLogin) {
            var width = mvpd.width;
            var height = mvpd.height;
            // Center on screen
            var top = (document.all) ? window.screenTop : window.screenY + 100;
            var left = (document.all) ? window.screenLeft : window.screenX + window.innerWidth / 2 - width / 2;

            mvpdWindow = window.open(aeHostname, "mvpdframe",
                           "width=" + width + ",height=" + height + ",top=" + top + ",left=" + left);
            // Monitor the mvpd popup for close
            if (!backgroundLogin) {
                clearInterval(cancelTimer);
                cancelTimer = setInterval(function () {
                    if (mvpdWindow && mvpdWindow.closed) {
                        clearInterval(cancelTimer);
                        $('#mvpddiv').hide();
                        accessEnablerAPI.setSelectedProvider(null);
                    }
                }, 200);
            }
        }
    }

recommendation-more-help

(Legacy) Accesso e disconnessione senza aggiornamento