Domande frequenti su REST API V2 rest-api-v2-faqs
Questo documento fornisce risposte generali elevate alle domande frequenti sull’adozione dell’API REST V2 per l’autenticazione di Adobe Pass.
Per ulteriori informazioni generali sull'API REST V2, consulta la documentazione Panoramica API REST V2.
Domande frequenti generali general-faqs
Inizia con questa sezione se stai lavorando su un'applicazione che deve integrare l'API REST V2, sia che si tratti di una nuova applicazione o di una esistente che esegue la migrazione da API REST V1 o SDK.
Per ulteriori informazioni sui dettagli e i passaggi della migrazione, consulta anche le sezioni successive.
Domande frequenti sulla fase di registrazione registration-phase-faqs-general
Domande frequenti sulla fase di configurazione configuration-phase-faqs-general
1. Qual è lo scopo della fase di configurazione? configuration-phase-faq1
Lo scopo della fase di configurazione è quello di fornire all’applicazione client l’elenco di MVPD con cui è attivamente integrata insieme ai dettagli di configurazione (ad esempio, id, displayName, logoUrl, ecc.) salvati dall’autenticazione di Adobe Pass per ogni MVPD.
La fase di configurazione funge da passaggio preliminare per la fase di autenticazione quando l'applicazione client deve richiedere all'utente di selezionare il proprio provider TV.
2. La fase di configurazione è obbligatoria? configuration-phase-faq2
La fase di configurazione non è obbligatoria, l’applicazione client deve recuperare la configurazione solo quando l’utente deve selezionare il proprio MVPD per l’autenticazione o la nuova autenticazione.
L’applicazione client può saltare questa fase nei seguenti scenari:
- Utente già autenticato.
- All'utente viene offerto l'accesso temporaneo tramite la funzionalità TempPass di base o promozionale.
- L’autenticazione dell’utente è scaduta, ma l’applicazione client ha memorizzato nella cache il MVPD selezionato in precedenza come scelta motivata dall’esperienza utente e richiede all’utente di confermare che è ancora un abbonato di quel MVPD.
3. Che cos’è una configurazione e per quanto tempo è valida? configuration-phase-faq3
La configurazione è un termine definito nella documentazione di Glossary.
La configurazione contiene un elenco di MVPD definiti dai seguenti attributi id, displayName, logoUrl e così via, che possono essere recuperati dall'endpoint Configuration.
L’applicazione client deve recuperare la configurazione solo quando l’utente deve selezionare il proprio MVPD per autenticarsi o autenticarsi di nuovo.
L’applicazione client può utilizzare la risposta di configurazione per presentare un selettore dell’interfaccia utente con le opzioni MVPD disponibili ogni volta che l’utente deve selezionare il proprio provider TV.
Per procedere con le fasi di autenticazione, preautorizzazione, autorizzazione o disconnessione, l'applicazione client deve memorizzare l'identificatore MVPD selezionato dell'utente, come specificato dall'attributo id del livello di configurazione di MVPD.
Per ulteriori informazioni, consulta la documentazione di Recupero configurazione.
4. L'applicazione client deve memorizzare nella cache le informazioni di risposta della configurazione in un archivio persistente? configuration-phase-faq4
L’applicazione client deve recuperare la configurazione solo quando l’utente deve selezionare il proprio MVPD per autenticarsi o autenticarsi di nuovo.
L’applicazione client deve memorizzare nella cache le informazioni sulla risposta di configurazione in un archivio di memoria per evitare richieste non necessarie e migliorare l’esperienza utente nei seguenti casi:
- Utente già autenticato.
- All'utente viene offerto l'accesso temporaneo tramite la funzionalità TempPass di base o promozionale.
- L’autenticazione dell’utente è scaduta, ma l’applicazione client ha memorizzato nella cache il MVPD selezionato in precedenza come scelta motivata dall’esperienza utente e richiede all’utente di confermare che è ancora un abbonato di quel MVPD.
5. L'applicazione client può gestire il proprio elenco di MVPD? configuration-phase-faq5
L’applicazione client può gestire il proprio elenco di MVPD, ma è necessario mantenere gli identificatori MVPD sincronizzati con l’autenticazione di Adobe Pass. Pertanto, si consiglia di utilizzare la configurazione fornita dall’autenticazione di Adobe Pass per garantire che l’elenco sia aggiornato e accurato.
L'applicazione client riceverebbe un errore dall'API REST di autenticazione di Adobe Pass V2 se l'identificatore MVPD fornito non è valido o se non dispone di un'integrazione attiva con il provider di servizi specificato.
6. L'applicazione client è in grado di filtrare l'elenco di MVPD? configuration-phase-faq6
L’applicazione client può filtrare l’elenco di MVPD forniti nella risposta di configurazione implementando un meccanismo personalizzato in base alla propria logica di business e ai requisiti, ad esempio la posizione dell’utente o la cronologia degli utenti della selezione precedente.
L'applicazione client può filtrare l'elenco di MVPD TempPass o MVPD con la relativa integrazione ancora in fase di sviluppo o test.
7. Cosa succede se l’integrazione con un MVPD è disabilitata e contrassegnata come inattiva? configuration-phase-faq7
Quando l’integrazione con un MVPD è disabilitata e contrassegnata come inattiva, il MVPD viene rimosso dall’elenco degli MVPD forniti nelle risposte di configurazione successive e ci sono due importanti conseguenze da considerare:
- Gli utenti non autenticati di quel MVPD non potranno più completare la fase di autenticazione utilizzando quel MVPD.
- Gli utenti autenticati di tale MVPD non saranno più in grado di completare le fasi di pre-autorizzazione, autorizzazione o disconnessione utilizzando tale MVPD.
L'applicazione client riceverebbe un errore dall'API REST di autenticazione di Adobe Pass V2 se l'utente selezionato per MVPD non dispone più di un'integrazione attiva con il provider di servizi specificato.
8. Cosa succede se l’integrazione con un MVPD è nuovamente abilitata e contrassegnata come attiva? configuration-phase-faq8
Quando l’integrazione con un MVPD viene nuovamente abilitata e contrassegnata come attiva, il MVPD viene incluso nuovamente nell’elenco di MVPD forniti nelle risposte di configurazione successive e ci sono due importanti conseguenze da considerare:
- Gli utenti non autenticati di quel MVPD saranno nuovamente in grado di completare la fase di autenticazione utilizzando quel MVPD.
- Gli utenti autenticati di tale MVPD potranno nuovamente completare le fasi di pre-autorizzazione, autorizzazione o disconnessione utilizzando tale MVPD.
9. Come abilitare o disabilitare l’integrazione con un MVPD? configuration-phase-faq9
Questa operazione può essere completata tramite Adobe Pass TVE Dashboard da uno degli amministratori dell'organizzazione o da un rappresentante di Adobe Pass Authentication che agisce per tuo conto.
Per ulteriori dettagli, consulta la Guida utente per l'integrazione del dashboard di TVE.
Domande frequenti sulla fase di autenticazione authentication-phase-faqs-general
1. Qual è lo scopo della fase di autenticazione? authentication-phase-faq1
Lo scopo della fase di autenticazione è quello di fornire all'applicazione client la capacità di verificare l'identità dell'utente e ottenere le informazioni sui metadati dell'utente.
La fase di autenticazione funge da passaggio preliminare per la fase di pre-autorizzazione o di autorizzazione quando l’applicazione client deve riprodurre il contenuto.
2. La fase di autenticazione è obbligatoria? authentication-phase-faq2
La fase di autenticazione è obbligatoria; l’applicazione client deve autenticare l’utente quando non dispone di un profilo valido nell’ambito dell’autenticazione di Adobe Pass.
L’applicazione client può saltare questa fase nei seguenti scenari:
- L’utente è già autenticato e il profilo è ancora valido.
- All'utente viene offerto l'accesso temporaneo tramite la funzionalità TempPass di base o promozionale.
La gestione degli errori dell'applicazione client richiede la gestione dei codici error (ad esempio authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated e così via), che indicano che l'applicazione client richiede l'autenticazione dell'utente.
3. Cos’è una sessione di autenticazione e per quanto tempo è valida? authentication-phase-faq3
La sessione di autenticazione è un termine definito nella documentazione di Glossary.
La sessione di autenticazione memorizza informazioni sul processo di autenticazione avviato che possono essere recuperate dall’endpoint Sessioni.
La sessione di autenticazione è valida per un periodo di tempo limitato e breve specificato al momento del problema dalla marca temporale notAfter, che indica il tempo necessario all'utente per completare il processo di autenticazione prima di richiedere il riavvio del flusso.
L'applicazione client può utilizzare la risposta della sessione di autenticazione per sapere come procedere con il processo di autenticazione. Tieni presente che in alcuni casi non è necessario eseguire l’autenticazione dell’utente, ad esempio fornendo un accesso temporaneo o ridotto oppure quando l’utente è già autenticato.
Per ulteriori informazioni, consulta i seguenti documenti:
- Crea API sessione di autenticazione
- Riprendi API sessione di autenticazione
- Flusso di autenticazione di base eseguito nell'applicazione principale
- Flusso di autenticazione di base eseguito nell'applicazione secondaria
4. Che cos’è un codice di autenticazione e per quanto tempo è valido? authentication-phase-faq4
Il codice di autenticazione è un termine definito nella documentazione di Glossary.
Il codice di autenticazione memorizza un valore univoco generato quando un utente avvia il processo di autenticazione e identifica in modo univoco la sessione di autenticazione di un utente fino al completamento del processo o alla scadenza della sessione di autenticazione.
Il codice di autenticazione è valido per un periodo di tempo limitato e breve specificato al momento dell'avvio della sessione di autenticazione tramite la marca temporale notAfter, che indica il tempo necessario all'utente per completare il processo di autenticazione prima di richiedere il riavvio del flusso.
L’applicazione client può utilizzare il codice di autenticazione per verificare se l’utente ha completato correttamente l’autenticazione e recuperare le informazioni sul profilo dell’utente, in genere tramite un meccanismo di polling.
L’applicazione client può inoltre utilizzare il codice di autenticazione per consentire all’utente di completare o riprendere il processo di autenticazione sullo stesso dispositivo o su un secondo dispositivo (schermo), considerando che la sessione di autenticazione non è scaduta.
Per ulteriori informazioni, consulta i seguenti documenti:
- Crea API sessione di autenticazione
- Riprendi API sessione di autenticazione
- Flusso di autenticazione di base eseguito nell'applicazione principale
- Flusso di autenticazione di base eseguito nell'applicazione secondaria
5. In che modo l'applicazione client può sapere se l'utente ha digitato un codice di autenticazione valido e se la sessione di autenticazione non è ancora scaduta? authentication-phase-faq5
L’applicazione client può convalidare il codice di autenticazione digitato dall’utente in un’applicazione secondaria (a schermo) inviando una richiesta a uno degli endpoint sessioni responsabili per riprendere la sessione di autenticazione o recuperare le informazioni sulla sessione di autenticazione associate al codice di autenticazione.
L'applicazione client riceverebbe un errore se il codice di autenticazione fornito fosse stato digitato in modo errato o se la sessione di autenticazione fosse scaduta.
Per ulteriori informazioni, consultare i documenti Riprendi sessione di autenticazione e Recupera sessione di autenticazione.
6. In che modo l’applicazione client può sapere se l’utente è già autenticato? authentication-phase-faq6
L’applicazione client può eseguire query su uno dei seguenti endpoint in grado di verificare se un utente è già autenticato e restituire informazioni sul profilo:
- API dell’endpoint "Profiles"
- Endpoint "profile" per API MVPD specifiche
- Endpoint "profile" per API di codice specifiche (di autenticazione)
Per ulteriori informazioni, consulta i seguenti documenti:
- Flusso dei profili di base eseguito all’interno dell’applicazione principale
- Flusso dei profili di base eseguito all'interno dell'applicazione secondaria
7. Che cos’è un profilo e per quanto tempo è valido? authentication-phase-faq7
Il profilo è un termine definito nella documentazione di Glossary.
Il profilo memorizza informazioni sulla validità dell’autenticazione dell’utente, sui metadati e molto altro ancora che può essere recuperato dall’endpoint "Profiles".
L’applicazione client può utilizzare il profilo per conoscere lo stato di autenticazione dell’utente, accedere alle informazioni sui metadati dell’utente, trovare il metodo utilizzato per l’autenticazione o l’entità utilizzata per fornire l’identità.
Per ulteriori informazioni, consulta i seguenti documenti:
- API dell’endpoint "Profiles"
- Endpoint "profile" per API MVPD specifiche
- Endpoint "profile" per API di codice specifiche (di autenticazione)
- Flusso dei profili di base eseguito all’interno dell’applicazione principale
- Flusso dei profili di base eseguito all'interno dell'applicazione secondaria
Il profilo è valido per un periodo di tempo limitato specificato quando viene eseguita una query con la marca temporale notAfter, che indica il periodo di tempo per cui l'utente dispone di un'autenticazione valida prima di richiedere di ripetere la fase di autenticazione.
Questo intervallo di tempo limitato, noto come autenticazione (authN) TTL, può essere visualizzato e modificato tramite Adobe Pass TVE Dashboard da uno degli amministratori dell'organizzazione o da un rappresentante di Adobe Pass Authentication che agisce per tuo conto.
Per ulteriori dettagli, consulta la Guida utente per l'integrazione del dashboard di TVE.
8. L'applicazione client deve memorizzare nella cache le informazioni del profilo dell'utente in una memoria persistente? authentication-phase-faq8
L’applicazione client deve memorizzare in cache parti delle informazioni del profilo utente in un archivio persistente per evitare richieste non necessarie e migliorare l’esperienza utente, considerando i seguenti aspetti:
| table 0-row-2 1-row-2 2-row-2 3-row-2 | |
|---|---|
| Attributo | Esperienza utente |
mvpd |
L'applicazione client può utilizzarlo per tenere traccia del provider TV selezionato dall'utente e continuare a utilizzarlo ulteriormente durante le fasi di pre-autorizzazione o autorizzazione. Alla scadenza del profilo utente corrente, l'applicazione client può utilizzare la selezione di MVPD memorizzata e chiedere conferma all'utente. |
attributes |
L'applicazione client può utilizzarlo per personalizzare l'esperienza utente in base a chiavi di metadati utente diverse (ad esempio, zip, maxRating, ecc.).I metadati utente diventano disponibili al termine del flusso di autenticazione, pertanto l'applicazione client non deve eseguire una query su un endpoint separato per recuperare le informazioni relative a metadati utente, in quanto sono già inclusi nelle informazioni del profilo. Alcuni attributi di metadati possono essere aggiornati durante il flusso di autorizzazione, a seconda di MVPD e dell'attributo di metadati specifico. Di conseguenza, l’applicazione client potrebbe dover eseguire nuovamente la query sulle API dei profili per recuperare i metadati dell’utente più recenti. |
notAfter |
L’applicazione client può utilizzarlo per tenere traccia della data di scadenza del profilo utente. La gestione degli errori dell'applicazione client richiede la gestione dei codici error (ad esempio, authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated e così via), che indicano che l'applicazione client richiede l'autenticazione dell'utente. |
9. L'applicazione client può estendere il profilo dell'utente senza richiedere una nuova autenticazione? authentication-phase-faq9
No.
Il profilo utente non può essere esteso oltre la sua validità senza l’interazione dell’utente, in quanto la sua scadenza è determinata dal TTL di autenticazione stabilito con gli MVPD.
Pertanto, l’applicazione client deve richiedere all’utente di autenticarsi nuovamente e interagire con la pagina di accesso di MVPD per aggiornare il proprio profilo sul sistema.
Tuttavia, per gli MVPD che supportano l'autenticazione basata su home (HBA), l'utente non dovrà immettere le credenziali.
10. Quali sono i casi d’uso per ogni endpoint Profili disponibile? authentication-phase-faq10
Gli endpoint di base per i profili sono progettati per fornire all’applicazione client la funzionalità di conoscere lo stato di autenticazione dell’utente, accedere alle informazioni sui metadati dell’utente, trovare il metodo utilizzato per l’autenticazione o l’entità utilizzata per fornire l’identità.
Ogni endpoint è adatto a un caso d’uso specifico, come segue:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| API | Descrizione | Caso d’uso |
| API endpoint profili | Recupera tutti i profili utente. | L'utente apre l'applicazione client per la prima volta In questo scenario, l'applicazione client non ha l'identificatore MVPD selezionato dell'utente memorizzato nella cache dell'archivio permanente. Di conseguenza, invierà una singola richiesta per recuperare tutti i profili utente disponibili. |
| Endpoint dei profili per API MVPD specifica | Recupera il profilo utente associato a un MVPD specifico. | L'utente ritorna all'applicazione client dopo l'autenticazione in una visita precedente In questo caso, l'applicazione client deve avere l'identificatore MVPD selezionato in precedenza memorizzato nella cache dell'archivio permanente. Di conseguenza, invierà una singola richiesta per recuperare il profilo dell'utente per quel MVPD specifico. |
| Endpoint dei profili per API di codice specifico (autenticazione) | Recupera il profilo utente associato a un codice di autenticazione specifico. | L'utente avvia il processo di autenticazione In questo caso, l'applicazione client deve determinare se l'utente ha completato correttamente l'autenticazione e recuperare le informazioni sul profilo. Verrà quindi avviato un meccanismo di polling per recuperare il profilo dell'utente associato al codice di autenticazione. |
Per ulteriori dettagli, fare riferimento al Flusso dei profili di base eseguito all'interno dell'applicazione principale e al Flusso dei profili di base eseguito all'interno dei documenti dell'applicazione secondaria.
L’endpoint SSO Profili ha uno scopo diverso e fornisce all’applicazione client la possibilità di creare un profilo utente utilizzando la risposta di autenticazione del partner e di recuperarlo in un’unica operazione una tantum.
| table 0-row-3 1-row-3 | ||
|---|---|---|
| API | Descrizione | Caso d’uso |
| Profili API endpoint SSO | Crea e recupera il profilo utente utilizzando la risposta di autenticazione del partner. | L'utente consente all'applicazione di utilizzare il Single Sign-On partner per l'autenticazione In questo caso, l'applicazione client deve creare un profilo utente dopo aver ricevuto la risposta di autenticazione partner e recuperarla in un'unica operazione. |
Per qualsiasi query successiva, è necessario utilizzare gli endpoint di base Profiles per determinare lo stato di autenticazione dell’utente, accedere alle informazioni sui metadati dell’utente, trovare il metodo utilizzato per l’autenticazione o l’entità utilizzata per fornire l’identità.
Per ulteriori dettagli, fare riferimento ai documenti Single Sign-On utilizzando i flussi dei partner e Apple SSO Cookbook (REST API V2).
11. Cosa deve fare l’applicazione client se l’utente dispone di più profili MVPD? authentication-phase-faq11
La decisione di supportare più profili dipende dai requisiti di business dell’applicazione client.
La maggior parte degli utenti avrà un solo profilo. Tuttavia, nei casi in cui esistono più profili (come descritto di seguito), l’applicazione client è responsabile di determinare la migliore esperienza utente per la selezione del profilo.
L’applicazione client può scegliere di richiedere all’utente di selezionare il profilo MVPD desiderato o di effettuare la selezione automaticamente, ad esempio scegliendo il primo profilo utente dalla risposta o quello con il periodo di validità più lungo.
REST API v2 supporta più profili per supportare:
- Utenti che potrebbero dover scegliere tra un profilo MVPD normale e uno ottenuto tramite Single Sign-On (SSO).
- Agli utenti viene offerto l’accesso temporaneo senza dover disconnettersi dal normale MVPD.
- Utenti con abbonamento a MVPD combinato con servizi Direct-to-Consumer (DTC).
- Utenti con più abbonamenti MVPD.
12. Cosa succede quando i profili utente scadono? authentication-phase-faq12
Quando i profili utente scadono, non vengono più inclusi nella risposta dall’endpoint "Profiles".
Se l’endpoint Profili restituisce una risposta di mappa dei profili vuota, l’applicazione client deve creare una nuova sessione di autenticazione e richiedere all’utente di ripetere l’autenticazione.
Per ulteriori informazioni, consulta la documentazione Creare l'API della sessione di autenticazione.
13. Quando i profili utente non sono più validi? authentication-phase-faq13
I profili utente non sono più validi nei seguenti scenari:
- Quando scade il TTL di autenticazione, come indicato dalla marca temporale
notAfternella risposta dell’endpoint Profili. - Quando l'applicazione client modifica il valore dell'intestazione AP-Device-Identifier.
- Quando l'applicazione client aggiorna le credenziali client utilizzate per recuperare il valore dell'intestazione Authorization.
- Quando l'applicazione client revoca o aggiorna l'istruzione software utilizzata per ottenere le credenziali del client.
14. Quando l’applicazione client deve avviare il meccanismo di polling? authentication-phase-faq14
Per garantire l’efficienza ed evitare richieste non necessarie, l’applicazione client deve avviare il meccanismo di polling nelle seguenti condizioni:
Autenticazione eseguita nell'applicazione primaria (schermata)
L'applicazione primaria (streaming) deve avviare il polling quando l'utente raggiunge la pagina di destinazione finale, dopo che il componente del browser carica l'URL specificato per il parametro redirectUrl nella richiesta dell'endpoint Sessions.
Autenticazione eseguita all'interno di un'applicazione secondaria (schermo)
L'applicazione principale (streaming) deve avviare il polling non appena l'utente avvia il processo di autenticazione, subito dopo aver ricevuto la risposta dell'endpoint Sessions e aver visualizzato il codice di autenticazione per l'utente.
15. Quando arrestare il meccanismo di polling nell'applicazione client? authentication-phase-faq15
Per garantire l’efficienza ed evitare richieste non necessarie, l’applicazione client deve arrestare il meccanismo di polling nelle seguenti condizioni:
Autenticazione completata
Le informazioni del profilo dell’utente vengono recuperate correttamente, confermando il loro stato di autenticazione. A questo punto, il polling non è più necessario.
Sessione di autenticazione e scadenza del codice
La sessione di autenticazione e il codice scadono, come indicato dalla marca temporale notAfter (ad esempio, 30 minuti) nella risposta dell'endpoint Sessions. In questo caso, l’utente deve riavviare il processo di autenticazione e arrestare immediatamente il polling che utilizza il codice di autenticazione precedente.
Nuovo codice di autenticazione generato
Se l’utente richiede un nuovo codice di autenticazione sul dispositivo principale (schermo), la sessione esistente non è più valida e il polling che utilizza il codice di autenticazione precedente deve essere interrotto immediatamente.
16. Quale intervallo tra le chiamate deve essere utilizzato dall'applicazione client per il meccanismo di polling? authentication-phase-faq16
Per garantire l'efficienza ed evitare richieste non necessarie, l'applicazione client deve configurare la frequenza del meccanismo di polling nelle seguenti condizioni:
| table 0-row-2 1-row-2 | |
|---|---|
| Autenticazione eseguita nell'applicazione primaria (schermata) | Autenticazione eseguita all'interno di un'applicazione secondaria (schermo) |
| L’applicazione principale (streaming) deve eseguire il polling ogni 3-5 secondi o più. | L’applicazione principale (streaming) deve eseguire il polling ogni 3-5 secondi o più. |
17. Qual è il numero massimo di richieste di polling che l'applicazione client può inviare? authentication-phase-faq17
L'applicazione client deve rispettare i limiti correnti definiti dal meccanismo di limitazione dell'autenticazione di Adobe Pass 🔗.
La gestione degli errori dell'applicazione client deve essere in grado di gestire il codice di errore 429 Troppe richieste, che indica che l'applicazione client ha superato il numero massimo di richieste consentito.
Per ulteriori dettagli, consulta la documentazione sul meccanismo di limitazione.
18. Come può l'applicazione client ottenere le informazioni sui metadati dell'utente? authentication-phase-faq18
L'applicazione client può eseguire una query su uno dei seguenti endpoint in grado di restituire informazioni sui metadati dell'utente come parte delle informazioni del profilo:
- API dell’endpoint "Profiles"
- Endpoint "profile" per API MVPD specifiche
- Endpoint "profile" per API di codice specifiche (di autenticazione)
I metadati utente diventano disponibili al termine del flusso di autenticazione, pertanto l'applicazione client non deve eseguire una query su un endpoint separato per recuperare le informazioni sui metadati utente, in quanto sono già inclusi nelle informazioni del profilo.
Per ulteriori informazioni, consulta i seguenti documenti:
- Flusso dei profili di base eseguito all’interno dell’applicazione principale
- Flusso dei profili di base eseguito all'interno dell'applicazione secondaria
Alcuni attributi di metadati possono essere aggiornati durante il flusso di autorizzazione, a seconda di MVPD e dell’attributo di metadati specifico. Di conseguenza, l’applicazione client potrebbe dover eseguire nuovamente la query sulle API di cui sopra per recuperare i metadati dell’utente più recenti.
19. In che modo l'applicazione client deve gestire l'accesso danneggiato? authentication-phase-faq19
La funzionalità di degradazione consente all'applicazione client di mantenere un'esperienza di streaming senza soluzione di continuità per gli utenti, anche quando i servizi di autenticazione o autorizzazione di MVPD incontrano problemi.
In sintesi, questo può garantire un accesso ininterrotto ai contenuti nonostante interruzioni temporanee del servizio MVPD.
Dato che l’organizzazione intende utilizzare la funzione di degradazione premium, l’applicazione client deve gestire flussi di accesso degradati, che delineano il comportamento degli endpoint REST API v2 in tali scenari.
Per ulteriori dettagli, consulta la documentazione sui flussi di accesso danneggiati.
20. In che modo l'applicazione client deve gestire l'accesso temporaneo? authentication-phase-faq20
La funzionalità TempPass consente all'applicazione client di fornire accesso temporaneo all'utente.
In sintesi, questo approccio può coinvolgere gli utenti fornendo un accesso limitato nel tempo ai contenuti o a un numero predefinito di titoli VOD per un periodo di tempo specificato.
Dato che la tua organizzazione intende utilizzare la funzione Premium TempPass, l’applicazione client deve gestire flussi di accesso temporanei che delineano il comportamento degli endpoint REST API v2 in tali scenari.
Nelle versioni API precedenti, l’applicazione client doveva disconnettersi da un utente autenticato con il proprio MVPD regolare per offrire un accesso temporaneo.
Con REST API v2, l’applicazione client può passare facilmente da un normale MVPD a un TempPass MVPD durante l’autorizzazione di un flusso, eliminando la necessità di disconnettersi dall’utente.
Per ulteriori dettagli, consulta la documentazione Flussi di accesso temporanei.
21. In che modo l'applicazione client deve gestire l'accesso single sign-on cross-device? authentication-phase-faq21
REST API v2 può abilitare il single sign-on tra dispositivi se l’applicazione client fornisce un identificatore utente univoco coerente tra i dispositivi.
Questo identificatore, noto come token di servizio, deve essere generato dall’applicazione client tramite l’implementazione o l’integrazione di un servizio Identity esterno di scelta.
Per ulteriori dettagli, consulta la documentazione Single Sign-On using Service Token Flow.
Domande frequenti sulla fase di pre-autorizzazione preauthorization-phase-faqs-general
1. Qual è lo scopo della fase di pre-autorizzazione? preauthorization-phase-faq1
Lo scopo della fase di pre-autorizzazione è quello di fornire all’applicazione client la capacità di presentare un sottoinsieme di risorse dal suo catalogo a cui l’utente avrebbe diritto di accedere.
La fase di preautorizzazione può migliorare l’esperienza utente quando l’utente apre l’applicazione client per la prima volta o passa a una nuova sezione.
2. La fase di pre-autorizzazione è obbligatoria? preauthorization-phase-faq2
La fase di pre-autorizzazione non è obbligatoria, l’applicazione client può saltare questa fase se desidera presentare un catalogo di risorse senza filtrarle prima in base al diritto dell’utente.
3. Che cos’è una decisione di preautorizzazione? preauthorization-phase-faq3
La pre-autorizzazione è un termine definito nella documentazione di Glossary, mentre il termine della decisione si trova anche nel Glossary.
La decisione di preautorizzazione memorizza informazioni sul risultato dell’interrogazione del processo di preautorizzazione di MVPD che possono essere recuperate dall’endpoint di preautorizzazione delle decisioni.
L’applicazione client può utilizzare le decisioni di preautorizzazione per presentare un sottoinsieme di risorse a cui l’utente può accedere in base alle decisioni (informative) del fornitore TV.
Per ulteriori informazioni, consulta i seguenti documenti:
- Recuperare l’API per le decisioni di preautorizzazione
- Flusso di pre-autorizzazione di base eseguito nell’applicazione principale
4. L'applicazione client deve memorizzare nella cache le decisioni di preautorizzazione in una memoria persistente? preauthorization-phase-faq4
L'applicazione client non è necessaria per archiviare le decisioni di preautorizzazione nell'archiviazione persistente. Tuttavia, si consiglia di memorizzare nella cache le decisioni sulle autorizzazioni per migliorare l’esperienza utente. Questo consente di evitare inutili chiamate all’endpoint Decisions Preauthorize per le risorse che sono già state preautorizzate, riducendo la latenza e migliorando le prestazioni.
5. In che modo l’applicazione del cliente può determinare il motivo per cui è stata negata una decisione di preautorizzazione? preauthorization-phase-faq5
L'applicazione client può determinare il motivo di una decisione di preautorizzazione negata esaminando il codice di errore e il messaggio inclusi nella risposta dall'endpoint di preautorizzazione delle decisioni. Questi dettagli forniscono ad insight il motivo specifico per cui la richiesta di preautorizzazione è stata negata, aiutando a informare l’esperienza utente o a attivare eventuali operazioni necessarie nell’applicazione.
Assicurati che eventuali meccanismi di esecuzione di nuovi tentativi implementati per recuperare le decisioni di preautorizzazione non generino un ciclo infinito se la decisione di preautorizzazione viene negata.
Valuta la possibilità di limitare i nuovi tentativi a un numero ragionevole e di gestire i rifiuti in modo appropriato fornendo all’utente un feedback chiaro.
6. Perché nella decisione di preautorizzazione manca un token multimediale? preauthorization-phase-faq6
Nella decisione di pre-autorizzazione manca un token multimediale perché la fase di pre-autorizzazione non deve essere utilizzata per riprodurre le risorse, in quanto questo è lo scopo della fase di autorizzazione.
7. È possibile saltare la fase di autorizzazione se esiste già una decisione di preautorizzazione? preauthorization-phase-faq7
No.
La fase di autorizzazione non può essere ignorata anche se è disponibile una decisione di preautorizzazione. Le decisioni di pre-autorizzazione sono solo informative e non concedono i diritti di riproduzione effettivi. La fase di pre-autorizzazione ha lo scopo di fornire indicazioni preliminari, ma la fase di autorizzazione è ancora necessaria prima di riprodurre qualsiasi contenuto.
8. Cos’è una risorsa e quali formati sono supportati? preauthorization-phase-faq8
La risorsa è un termine definito nella documentazione di Glossary.
La risorsa è un identificatore univoco concordato con gli MVPD ed è associata a un contenuto che l’applicazione client può inviare in streaming.
L’identificatore univoco della risorsa può avere due formati:
- Un formato di stringa semplice, ad esempio un identificatore univoco per un canale (brand).
- Un formato RSS per contenuti multimediali (MRSS) contenente informazioni aggiuntive come il titolo, le valutazioni e i metadati per il controllo genitori.
Per ulteriori dettagli, consulta la documentazione di Risorse protette.
9. Per quante risorse l'applicazione client può ottenere una decisione di preautorizzazione alla volta? preauthorization-phase-faq9
L’applicazione client può ottenere una decisione di preautorizzazione per un numero limitato di risorse in una singola richiesta API, di solito fino a 5, a causa delle condizioni imposte dagli MVPD.
Questo numero massimo di risorse può essere visualizzato e modificato dopo aver concordato con gli MVPD tramite Adobe Pass TVE Dashboard da uno degli amministratori dell'organizzazione o da un rappresentante di autenticazione Adobe Pass che agisce per tuo conto.
Per ulteriori dettagli, consulta la Guida utente per l'integrazione del dashboard di TVE.
Domande frequenti sulla fase di autorizzazione authorization-phase-faqs-general
1. Qual è lo scopo della fase di autorizzazione? authorization-phase-faq1
Lo scopo della fase di autorizzazione è quello di fornire all’applicazione client la capacità di riprodurre le risorse richieste dall’utente dopo aver convalidato i propri diritti con MVPD.
2. La fase di autorizzazione è obbligatoria? authorization-phase-faq2
La fase di autorizzazione è obbligatoria, l’applicazione client non può saltare questa fase se desidera riprodurre le risorse richieste dall’utente, in quanto richiede la verifica con il MVPD che l’utente abbia diritto prima di rilasciare il flusso.
3. Cos’è una decisione di autorizzazione e per quanto tempo è valida? authorization-phase-faq3
L'autorizzazione è un termine definito nella documentazione di Glossary, mentre il termine della decisione si trova anche nel Glossary.
La decisione di autorizzazione memorizza informazioni sul risultato della richiesta di informazioni del processo di autorizzazione di MVPD che possono essere recuperate dall’endpoint "Decisions Authorize".
L’applicazione client può utilizzare la decisione di autorizzazione contenente un token multimediale per riprodurre il flusso di risorse nel caso in cui la decisione del fornitore TV (autorevole) consenta all’utente di accedervi.
Per ulteriori informazioni, consulta i seguenti documenti:
- Recuperare l’API per le decisioni di autorizzazione
- Flusso di autorizzazione di base eseguito nell'applicazione principale
La decisione di autorizzazione è valida per un periodo di tempo limitato e breve specificato al momento del rilascio, che indica il periodo di tempo in cui verrà memorizzata nella cache dall’autenticazione di Adobe Pass prima che venga richiesto di eseguire nuovamente la query sul MVPD.
Questo periodo di tempo limitato, noto come autorizzazione (authZ) TTL, può essere visualizzato e modificato tramite Adobe Pass TVE Dashboard da uno degli amministratori dell'organizzazione o da un rappresentante di Adobe Pass Authentication che agisce per tuo conto.
Per ulteriori dettagli, consulta la Guida utente per l'integrazione del dashboard di TVE.
4. L'applicazione client deve memorizzare nella cache le decisioni di autorizzazione in una memoria persistente? authorization-phase-faq4
L'applicazione client non è necessaria per archiviare le decisioni di autorizzazione nell'archivio permanente.
5. In che modo l’applicazione del cliente può determinare il motivo per cui è stata rifiutata una decisione di autorizzazione? authorization-phase-faq5
L'applicazione client può determinare il motivo di una decisione di autorizzazione negata esaminando il codice di errore e il messaggio inclusi nella risposta dall'endpoint Decisions Authorize. Questi dettagli forniscono ad insight il motivo specifico per cui la richiesta di autorizzazione è stata negata, aiutando a informare l’esperienza utente o a attivare eventuali operazioni necessarie nell’applicazione.
Assicurati che eventuali meccanismi di esecuzione di nuovi tentativi implementati per recuperare le decisioni di autorizzazione non generino un loop infinito se la decisione di autorizzazione viene negata.
Valuta la possibilità di limitare i nuovi tentativi a un numero ragionevole e di gestire i rifiuti in modo appropriato fornendo all’utente un feedback chiaro.
6. Cos’è un token multimediale e per quanto tempo è valido? authorization-phase-faq6
Il token multimediale è un termine definito nella documentazione di Glossary.
Il token multimediale è costituito da una stringa firmata inviata in testo non crittografato che può essere recuperata dall’endpoint Autorizzazione decisioni.
Per ulteriori informazioni, consulta la documentazione di Media Token Verifier.
Il token multimediale è valido per un periodo di tempo limitato e breve specificato al momento del rilascio, che indica il limite di tempo prima che debba essere verificato e utilizzato dall’applicazione client.
L’applicazione client può utilizzare il token multimediale per riprodurre un flusso di risorse nel caso in cui la decisione del fornitore TV (autorevole) consenta all’utente di accedervi.
Per ulteriori informazioni, consulta i seguenti documenti:
- Recuperare l’API per le decisioni di autorizzazione
- Flusso di autorizzazione di base eseguito nell'applicazione principale
7. L’applicazione client deve convalidare il token multimediale prima di riprodurre il flusso di risorse? authorization-phase-faq7
Sì.
L’applicazione client deve convalidare il token multimediale prima di avviare la riproduzione del flusso di risorse. Questa convalida deve essere eseguita utilizzando Media Token Verifier. Verificando serializedToken da token restituito, l'applicazione client impedisce l'accesso non autorizzato, ad esempio la copia di flusso, e garantisce che solo gli utenti autorizzati possano riprodurre il contenuto.
8. L’applicazione client deve aggiornare un token multimediale scaduto durante la riproduzione? authorization-phase-faq8
No.
Non è necessario che l’applicazione client aggiorni un token multimediale scaduto mentre il flusso è in riproduzione attiva. Se il token multimediale scade durante la riproduzione, il flusso deve poter continuare senza interruzioni. Tuttavia, il client deve richiedere una nuova decisione di autorizzazione e ottenere un nuovo token multimediale la volta successiva che l’utente tenta di riprodurre una risorsa.
9. Qual è lo scopo di ciascun attributo di marca temporale nella decisione di autorizzazione? authorization-phase-faq9
La decisione di autorizzazione include diversi attributi di marca temporale che forniscono un contesto essenziale sul periodo di validità dell’autorizzazione stessa e del token multimediale associato. Queste marche temporali hanno scopi diversi, a seconda che si riferiscano alla decisione di autorizzazione o al token multimediale.
Marca temporale a livello di decisione
Le marche temporali descrivono il periodo di validità della decisione globale di autorizzazione:
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Attributo | Descrizione | Note |
notBefore |
Tempo in millisecondi in cui è stata rilasciata la decisione di autorizzazione. | Indica l'inizio della finestra di validità dell'autorizzazione. |
notAfter |
Tempo in millisecondi in cui scade la decisione di autorizzazione. | Il valore TTL authorization Time-to-Live determina per quanto tempo l'autorizzazione rimane valida prima di richiedere una nuova autorizzazione. Questo TTL viene negoziato con i rappresentanti di MVPD. |
Marca temporale a livello di token
Queste marche temporali descrivono il periodo di validità del token multimediale associato alla decisione di autorizzazione:
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Attributo | Descrizione | Note |
notBefore |
Tempo in millisecondi in cui è stato emesso il token multimediale. | Indica quando il token diventa valido per la riproduzione. |
notAfter |
Tempo in millisecondi in cui scade il token multimediale. | I token multimediali hanno una durata intenzionalmente breve (in genere 7 minuti) per ridurre al minimo i rischi di uso improprio e tenere conto delle potenziali differenze di clock tra il server che genera i token e il server che verifica i token. |
10. Che cos’è una risorsa e quali formati sono supportati? authorization-phase-faq10
La risorsa è un termine definito nella documentazione di Glossary.
La risorsa è un identificatore univoco concordato con gli MVPD ed è associata a un contenuto che l’applicazione client può inviare in streaming.
L’identificatore univoco della risorsa può avere due formati:
- Un formato di stringa semplice, ad esempio un identificatore univoco per un canale (brand).
- Un formato RSS per contenuti multimediali (MRSS) contenente informazioni aggiuntive come il titolo, le valutazioni e i metadati per il controllo genitori.
Per ulteriori dettagli, consulta la documentazione di Risorse protette.
11. Per quante risorse la domanda del cliente può ottenere una decisione di autorizzazione alla volta? authorization-phase-faq11
L’applicazione client può ottenere una decisione di autorizzazione per un numero limitato di risorse in una singola richiesta API, di solito fino a 1, a causa delle condizioni imposte dagli MVPD.
Domande frequenti sulla fase di disconnessione logout-phase-faqs-general
1. Qual è lo scopo della fase di disconnessione? logout-phase-faq1
Lo scopo della fase di disconnessione è fornire all’applicazione client la funzionalità per terminare il profilo autenticato dell’utente nell’ambito dell’autenticazione di Adobe Pass su richiesta dell’utente.
2. La fase di disconnessione è obbligatoria? logout-phase-faq2
La fase di disconnessione è obbligatoria, l'applicazione client deve fornire all'utente la possibilità di disconnettersi.
Domande frequenti sulle intestazioni headers-faqs-general
1. Come calcolare il valore per l’intestazione Autorizzazione? headers-faq1
| note important |
|---|
| IMPORTANT |
Se l'applicazione client esegue la migrazione dall'API REST V1 all'API REST V2, l'applicazione client può continuare a utilizzare lo stesso metodo per ottenere il valore del token di accesso Bearer come in precedenza. |
L'intestazione della richiesta Authorization contiene il token di accesso Bearer richiesto dall'applicazione client per accedere alle API protette di Adobe Pass.
Il valore dell’intestazione Authorization deve essere ottenuto dall’autenticazione di Adobe Pass durante la fase di registrazione.
Per ulteriori informazioni, consulta i seguenti documenti:
- Panoramica di Registrazione client dinamici
- Recupera API credenziali client
- Recupera API token di accesso
- Flusso di registrazione client dinamici
2. Come calcolare il valore per l’intestazione AP-Device-Identifier? headers-faq2
| note important |
|---|
| IMPORTANT |
| Se l’applicazione client esegue la migrazione dall’API REST V1 all’API REST V2, può continuare a utilizzare lo stesso metodo per calcolare il valore dell’identificatore del dispositivo come in precedenza. |
L'intestazione della richiesta AP-Device-Identifier contiene l'identificatore del dispositivo di streaming creato dall'applicazione client.
La documentazione dell'intestazione AP-Device-Identifier fornisce esempi per le piattaforme principali su come calcolare il valore, ma l'applicazione client può scegliere di utilizzare un metodo diverso in base alla propria logica di business e ai propri requisiti.
3. Come calcolare il valore per l’intestazione X-Device-Info? headers-faq3
| note important |
|---|
| IMPORTANT |
| Se l’applicazione client esegue la migrazione dall’API REST V1 all’API REST V2, può continuare a utilizzare lo stesso metodo per calcolare il valore delle informazioni sul dispositivo. |
L'intestazione della richiesta X-Device-Info contiene le informazioni client (dispositivo, connessione e applicazione) relative al dispositivo di streaming effettivo e viene utilizzata per determinare le regole specifiche della piattaforma che gli MVPD possono applicare.
La documentazione dell'intestazione X-Device-Info fornisce esempi per le piattaforme principali su come calcolare il valore, ma l'applicazione client può scegliere di utilizzare un metodo diverso in base alla propria logica di business e ai propri requisiti.
Se l'intestazione X-Device-Info è mancante o contiene valori non corretti, la richiesta potrebbe essere classificata come proveniente da una piattaforma unknown.
Questo può comportare che la richiesta venga trattata come non sicura e soggetta a regole più restrittive, ad esempio TTL di autenticazione più brevi. Inoltre, alcuni campi, ad esempio il dispositivo di streaming connectionIp e connectionPort, sono obbligatori per funzionalità quali Autenticazione di base di base di Spectrum.
Anche quando la richiesta proviene da un server per conto di un dispositivo, il valore dell'intestazione X-Device-Info deve riflettere le informazioni effettive sul dispositivo di streaming.
Domande frequenti varie misc-faqs-general
1. Posso esplorare le richieste e le risposte REST API V2 e testare l’API? misc-faq1
Sì.
Puoi esplorare REST API V2 tramite il nostro sito Web dedicato Adobe Developer. Il sito web di Adobe Developer fornisce accesso illimitato a:
Per interagire con API REST V2, è necessario includere l'intestazione Authorization con un token di accesso Bearer ottenuto tramite l'API DCR.
Per utilizzare l'API DCR, è necessaria un'istruzione software con ambito REST API V2. Per ulteriori dettagli, consulta il documento Domande frequenti sulla registrazione client dinamica (DCR).
2. Posso esplorare le richieste e le risposte REST API V2 utilizzando uno strumento di sviluppo API con supporto OpenAPI? misc-faq2
Sì.
Puoi scaricare i file delle specifiche OpenAPI per l'API DCR e l'API REST V2 dal sito Web Adobe Developer.
Per scaricare i file delle specifiche OpenAPI, fare clic sui pulsanti di download per salvare i seguenti file nel computer locale:
Puoi quindi importare questi file nello strumento di sviluppo API preferito per esplorare le richieste e le risposte REST API V2 e testare l’API.
3. Posso continuare a utilizzare lo strumento di test API esistente ospitato su https://sp.auth-staging.adobe.com/apitest/api.html? misc-faq3
No.
Le applicazioni client che eseguono la migrazione all’API REST V2 devono utilizzare il nuovo strumento di test ospitato in https://developer.adobe.com/adobe-pass/. Il sito web di Adobe Developer fornisce accesso illimitato a:
Per interagire con API REST V2, è necessario includere l'intestazione Authorization con un token di accesso Bearer ottenuto tramite l'API DCR.
Per utilizzare l'API DCR, è necessaria un'istruzione software con ambito REST API V2. Per ulteriori dettagli, consulta il documento Domande frequenti sulla registrazione client dinamica (DCR).
Domande frequenti sulla migrazione migration-faqs
Continuare con questa sezione se si sta lavorando su un'applicazione che deve migrare un'applicazione esistente all'API REST V2.
Domande frequenti sulla migrazione generali general-migration-faqs
1. È necessario eseguire il rollout di una nuova applicazione client migrata all’API REST V2 per tutti gli utenti contemporaneamente? migration-faq1
No.
Non è necessario che l’applicazione client distribuisca una nuova versione che integra l’API REST V2 a tutti gli utenti simultaneamente.
L’autenticazione di Adobe Pass continuerà a supportare le versioni precedenti delle applicazioni client che integrano l’API REST V1 o SDK fino alla fine del 2025.
2. È necessario implementare una nuova applicazione client migrata all’API REST V2 in tutte le API e i flussi contemporaneamente? migration-faq2
Sì.
L’applicazione client deve distribuire una nuova versione che integri l’API REST V2 in tutte le API e i flussi di autenticazione di Adobe Pass simultaneamente.
Nel caso del flusso di autenticazione della seconda schermata, l'applicazione client deve eseguire il rollout di una nuova versione che integra l'API REST V2 per le applicazioni primary e secondary simultaneamente.
L’autenticazione Adobe Pass non supporterà implementazioni "ibride" che integrano sia l’API REST V2 che l’API REST V1/SDK tra API e flussi.
3. L’autenticazione utente verrà mantenuta durante l’aggiornamento a una nuova applicazione client migrata all’API REST V2? migration-faq3
No.
L’autenticazione utente ottenuta nelle versioni precedenti dell’applicazione client che integrano l’API REST V1 o SDK non verrà mantenuta.
Pertanto, all’utente verrà richiesto di autenticare nuovamente all’interno della nuova applicazione client migrata all’API REST V2.
4. I codici di errore avanzati sono abilitati per impostazione predefinita nell’API REST V2? migration-faq4
Sì.
Per impostazione predefinita, le applicazioni client che eseguono la migrazione all’API REST V2 beneficiano automaticamente di questa funzione, fornendo informazioni di errore più dettagliate e precise.
Per ulteriori dettagli, consulta la documentazione sui codici di errore avanzati.
5. Le integrazioni esistenti richiedono modifiche alla configurazione durante la migrazione all’API REST V2? migration-faq5
No.
Le applicazioni client che eseguono la migrazione all’API REST V2 non richiedono modifiche di configurazione per le integrazioni MVPD esistenti. Inoltre, continueranno a utilizzare gli stessi identificatori per provider di servizi e MVPD esistenti.
Inoltre, i protocolli utilizzati dall’autenticazione di Adobe Pass per comunicare con gli endpoint di MVPD rimangono invariati.
Migrazione da REST API V1 a REST API V2 migration-rest-api-v1-to-rest-api-v2-faqs
Continua con questa sottosezione se stai lavorando su un’applicazione che deve migrare dall’API REST V1 all’API REST V2.
Domande frequenti sulla fase di registrazione registration-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di registrazione? registration-phase-v1-to-v2-faq1
Nella migrazione dall’API REST V1 all’API REST V2 non vi sono modifiche di alto livello per quanto riguarda la fase di registrazione.
L'applicazione client può continuare a utilizzare lo stesso flusso per eseguire la registrazione in base all'autenticazione Adobe Pass tramite il processo Dynamic Client Registration (DCR) e ottenere un token di accesso.
Per ulteriori informazioni, consulta i seguenti documenti:
Domande frequenti sulla fase di configurazione configuration-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di configurazione? configuration-phase-v1-to-v2-faq1
Nella migrazione dall’API REST V1 all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nella tabella seguente:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | API REST V1 | API REST V2 | Osservazioni |
| Recupera elenco di MVPD con integrazione attiva | GET /api/v1/config/{serviceProvider} |
GET /api/v2/{serviceProvider}/configurazione |
Domande frequenti sulla fase di autenticazione authentication-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di autenticazione? authentication-phase-v1-to-v2-faq1
Nella migrazione dall’API REST V1 all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nella tabella seguente:
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 7-row-4 | |||
|---|---|---|---|
| Ambito | API REST V1 | API REST V2 | Osservazioni |
| Recupera codice di registrazione (codice di autenticazione) | POST /reggie/v1/{serviceProvider}/regcode |
POST /api/v2/{serviceProvider}/session |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verifica il codice di registrazione (codice di autenticazione) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/session/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Riprendi autenticazione (MVPD) nella seconda schermata (applicazione) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/session/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Avvia autenticazione (MVPD) | GET /api/v1/authenticate |
GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verificare lo stato di autenticazione dell’utente | GET /api/v1/checkauthn (prima schermata) GET /api/v1/checkauthn (seconda schermata) |
Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare il token di autenticazione utente (profilo) | GET /api/v1/tokens/authn |
Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare le informazioni sui metadati dell’utente | GET /api/v1/tokens/usermetadata |
Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di pre-autorizzazione preauthorization-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello richieste per la fase di pre-autorizzazione? preauthorization-phase-v1-to-v2-faq1
Nella migrazione dall’API REST V1 all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nella tabella seguente:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | API REST V1 | API REST V2 | Osservazioni |
| Recuperare risorse autorizzate (decisioni di preautorizzazione) | GET /api/v1/preauthorize (prima schermata) GET /api/v1/preauthorize (seconda schermata) |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di autorizzazione authorization-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di autorizzazione? authorization-phase-v1-to-v2-faq1
Nella migrazione dall’API REST V1 all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nella tabella seguente:
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ambito | API REST V1 | API REST V2 | Osservazioni |
| Avvia autorizzazione (MVPD) | GET /api/v1/authorize |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recupera token di autorizzazione (decisione di autorizzazione) | GET /api/v1/tokens/authz |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recupera token di autorizzazione breve (token multimediale) | GET /api/v1/tokens/media |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di disconnessione logout-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di disconnessione? logout-phase-v1-to-v2-faq1
Nella migrazione dall’API REST V1 all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nella tabella seguente:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | API REST V1 | API REST V2 | Osservazioni |
| Avvia disconnessione | GET /api/v1/logout |
GET /api/v2/{serviceProvider}/logout |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Migrazione da SDK all’API REST V2 migration-sdk-to-rest-api-v2
Continua con questa sottosezione se stai lavorando su un’applicazione che deve migrare da SDK all’API REST V2.
Domande frequenti sulla fase di registrazione registration-phase-faqs-migration-sdk-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di registrazione? registration-phase-sdk-to-v2-faq1
Nella migrazione dagli SDK all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nelle tabelle seguenti:
SDK di AccessEnabler JavaScript
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Registrazione client dinamica (DCR) completa | Fornitura di istruzioni software al costruttore | POST /o/client/register GET /o/client/token |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Registrazione client dinamica (DCR) completa | Fornitura di istruzioni software al costruttore | POST /o/client/register GET /o/client/token |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler Android
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Registrazione client dinamica (DCR) completa | Fornitura di istruzioni software al costruttore | POST /o/client/register GET /o/client/token |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Registrazione client dinamica (DCR) completa | Fornitura di istruzioni software al costruttore | POST /o/client/register GET /o/client/token |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di configurazione configuration-phase-faqs-migration-sdk-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di configurazione? configuration-phase-sdk-to-v2-faq1
Nella migrazione dagli SDK all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nelle tabelle seguenti:
SDK di AccessEnabler JavaScript
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera elenco di MVPD con integrazione attiva | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configurazione |
SDK di AccessEnabler iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera elenco di MVPD con integrazione attiva | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configurazione |
SDK di AccessEnabler Android
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera elenco di MVPD con integrazione attiva | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configurazione |
SDK di AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera elenco di MVPD con integrazione attiva | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configurazione |
Domande frequenti sulla fase di autenticazione authentication-phase-faqs-migration-sdk-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di autenticazione? authentication-phase-sdk-to-v2-faq1
Nella migrazione dagli SDK all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nelle tabelle seguenti:
SDK di AccessEnabler JavaScript
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia autenticazione (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verificare lo stato di autenticazione dell’utente | AccessEnabler.checkAuthentication | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare le informazioni sui metadati dell’utente | AccessEnabler.getMetadata | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler iOS
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia autenticazione (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verificare lo stato di autenticazione dell’utente | AccessEnabler.checkAuthentication | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare le informazioni sui metadati dell’utente | AccessEnabler.getMetadata | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler tvOS
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera codice di registrazione (codice di autenticazione) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verifica il codice di registrazione (codice di autenticazione) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/session/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Riprendi autenticazione (MVPD) nella seconda schermata (applicazione) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/session/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Avvia autenticazione (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verificare lo stato di autenticazione dell’utente | AccessEnabler.checkAuthentication | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare le informazioni sui metadati dell’utente | AccessEnabler.getMetadata | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler Android
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia autenticazione (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verificare lo stato di autenticazione dell’utente | AccessEnabler.checkAuthentication | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare le informazioni sui metadati dell’utente | AccessEnabler.getMetadata | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler FireOS
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera codice di registrazione (codice di autenticazione) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verifica il codice di registrazione (codice di autenticazione) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider}/session/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Riprendi autenticazione (MVPD) nella seconda schermata (applicazione) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider}/session/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Avvia autenticazione (MVPD) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/session GET /api/v2/authenticate/{serviceProvider}/{code} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Verificare lo stato di autenticazione dell’utente | AccessEnabler.checkAuthentication | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| Recuperare le informazioni sui metadati dell’utente | AccessEnabler.getMetadata | Utilizzare uno dei seguenti: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
L'applicazione client può utilizzare la risposta di queste API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di pre-autorizzazione preauthorization-phase-faqs-migration-sdk-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello richieste per la fase di pre-autorizzazione? preauthorization-phase-sdk-to-v2-faq1
Nella migrazione dagli SDK all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nelle tabelle seguenti:
SDK di AccessEnabler JavaScript
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recuperare risorse autorizzate (decisioni di preautorizzazione) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recuperare risorse autorizzate (decisioni di preautorizzazione) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler Android
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recuperare risorse autorizzate (decisioni di preautorizzazione) | AccessEnabler.checkPreauthorizedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recuperare risorse autorizzate (decisioni di preautorizzazione) | AccessEnabler.checkPreauthorizedResources | POST /api/v2/{serviceProvider}/decision/preauthorize/{mvpd} |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di autorizzazione authorization-phase-faqs-migration-sdk-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di autorizzazione? authorization-phase-sdk-to-v2-faq1
Nella migrazione dagli SDK all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nelle tabelle seguenti:
SDK di AccessEnabler JavaScript
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera token di autorizzazione breve (token multimediale) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera token di autorizzazione breve (token multimediale) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler Android
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera token di autorizzazione breve (token multimediale) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Recupera token di autorizzazione breve (token multimediale) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
PUBBLICA /api/v2/{serviceProvider}/decision/authorize/{mvpd} |
L'applicazione client può utilizzare la risposta di questa API per più scopi contemporaneamente:
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
Domande frequenti sulla fase di disconnessione logout-phase-faqs-migration-sdk-to-rest-api-v2
1. Quali sono le migrazioni API di alto livello necessarie per la fase di disconnessione? logout-phase-sdk-to-v2-faq1
Nella migrazione dagli SDK all’API REST V2 sono presenti modifiche di alto livello da considerare presentate nelle tabelle seguenti:
SDK di AccessEnabler JavaScript
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia disconnessione | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler iOS/tvOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia disconnessione | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler Android
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia disconnessione | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |
SDK di AccessEnabler FireOS
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Ambito | SDK | API REST V2 | Osservazioni |
| Avvia disconnessione | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Per ulteriori dettagli, fare riferimento ai seguenti documenti: |