Veelgestelde vragen over REST API V2 rest-api-v2-faqs
Dit document biedt een uitgebreid overzicht van de antwoorden op veelgestelde vragen over de Adobe Pass Authentication REST API V2-toepassing.
Voor meer informatie over REST API V2 algemeen, zie de REST API V2- Overzicht documentatie.
Algemene veelgestelde vragen general-faqs
Begin met deze sectie als u aan een toepassing werkt die REST API V2 moet integreren, of het een nieuwe toepassing of bestaande is die van REST API V1 of SDK migreert.
Zie ook de volgende secties voor meer informatie over migratiedetails en -stappen.
Veelgestelde vragen over de registratiefase registration-phase-faqs-general
Veelgestelde vragen over de configuratiefase configuration-phase-faqs-general
1. Wat is het doel van de fase van de Configuratie? configuration-phase-faq1
Het doel van de configuratiefase is om de clienttoepassing een lijst met MVPD's te geven waarmee deze actief is geïntegreerd, samen met configuratiegegevens (bijvoorbeeld id , displayName , logoUrl , enz.) die zijn opgeslagen door Adobe Pass Authentication voor elke MVPD.
De configuratiefase fungeert als een noodzakelijke stap voor de verificatiefase wanneer de clienttoepassing de gebruiker moet vragen zijn of haar tv-provider te selecteren.
2. Is de configuratiefase verplicht? configuration-phase-faq2
De configuratiefase is niet verplicht. De clienttoepassing moet de configuratie alleen ophalen wanneer de gebruiker zijn MVPD moet selecteren om te worden geverifieerd of opnieuw te worden geverifieerd.
De cliënttoepassing kan deze fase in de volgende scenario's overslaan:
- De gebruiker is al geverifieerd.
- De gebruiker wordt aangeboden tijdelijke toegang door basis of promotionele eigenschap TempPass.
- De gebruikersverificatie is verlopen, maar de clienttoepassing heeft de eerder geselecteerde MVPD in de cache geplaatst als een gebruikerservaring die de keuze motiveert. De gebruiker wordt alleen gevraagd te bevestigen dat hij of zij nog steeds een abonnee van die MVPD is.
3. Wat is een configuratie en hoe lang is deze geldig? configuration-phase-faq3
De configuratie is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
De configuratie bevat een lijst van MVPDs die door de volgende attributen id wordt bepaald, displayName, logoUrl, enz., die van het 4} eindpunt van de Configuratie kan worden teruggewonnen.
De clienttoepassing moet de configuratie alleen ophalen wanneer de gebruiker zijn MVPD moet selecteren om te worden geverifieerd of opnieuw te worden geverifieerd.
De clienttoepassing kan de configuratiereactie gebruiken om een UI-kiezer met beschikbare MVPD-opties weer te geven wanneer de gebruiker zijn tv-provider moet selecteren.
De clienttoepassing moet de door de gebruiker geselecteerde MVPD-id, zoals opgegeven door het MVPD-kenmerk configuration-level id , opslaan om door te gaan met de fasen Verificatie, Voortoelating, Autorisatie of Afmelden.
Voor meer informatie, verwijs naar terugwinnen configuratie documentatie.
4. Is de configuratie specifiek voor een dienstverlener, platform, of gebruiker? configuration-phase-faq4
De configuratie is specifiek voor a dienstverlener .
De configuratie is specifiek voor een platformtype.
De configuratie is niet specifiek voor een gebruiker.
Voor cliënttoepassingen die een server-aan-server architectuur gebruiken, wordt het geadviseerd om de configuratiereactie (b.v., met 2 minieme TTL) voor elk platformtype in server-zijgeheugenopslag in het voorgeheugen onder te brengen. Dit vermindert onnodige verzoeken voor elke gebruiker en verbetert algemene gebruikerservaring.
5. Moet de client-toepassing de informatie over de configuratiereactie in cache plaatsen in een permanente opslag? configuration-phase-faq5
| note important |
|---|
| IMPORTANT |
| Voor cliënttoepassingen die een server-aan-server architectuur gebruiken, wordt het geadviseerd om de configuratiereactie (b.v., met 2 minieme TTL) voor elk platformtype in server-zijgeheugenopslag in het voorgeheugen onder te brengen. Dit vermindert onnodige verzoeken voor elke gebruiker en verbetert algemene gebruikerservaring. |
De clienttoepassing moet de configuratie alleen ophalen wanneer de gebruiker zijn MVPD moet selecteren om te worden geverifieerd of opnieuw te worden geverifieerd.
De cliënttoepassing zou de informatie van de configuratiereactie in een geheugenopslag in het voorgeheugen moeten opslaan om onnodige verzoeken te vermijden en de gebruikerservaring te verbeteren wanneer:
- De gebruiker is al geverifieerd.
- De gebruiker wordt aangeboden tijdelijke toegang door basis of promotionele eigenschap TempPass.
- De gebruikersverificatie is verlopen, maar de clienttoepassing heeft de eerder geselecteerde MVPD in de cache geplaatst als een gebruikerservaring die de keuze motiveert. De gebruiker wordt alleen gevraagd te bevestigen dat hij of zij nog steeds een abonnee van die MVPD is.
6. Kan de clienttoepassing zijn eigen lijst met MVPD's beheren? configuration-phase-faq6
De clienttoepassing kan een eigen lijst met MVPD's beheren, maar de MVPD-id's moeten synchroon blijven met de Adobe Pass-verificatie. Daarom wordt aangeraden de configuratie te gebruiken die door Adobe Pass Authentication wordt geleverd om ervoor te zorgen dat de lijst up-to-date en accuraat is.
De cliënttoepassing zou een fout van de Authentificatie van Adobe Pass REST API V2 ontvangen als het verstrekte herkenningsteken van MVPD ongeldig is of in het geval heeft het geen actieve integratie met de gespecificeerde dienstverlener .
7. Kan de clienttoepassing de lijst met MVPD's filteren? configuration-phase-faq7
De cliënttoepassing kan de lijst van MVPDs filtreren die in de configuratiereactie wordt verstrekt door een douanemechanisme uit te voeren dat op zijn eigen bedrijfslogica en vereisten zoals gebruikersplaats of gebruikersgeschiedenis van vorige selectie wordt gebaseerd.
De cliënttoepassing kan de lijst van TempPass MVPDs of MVPDs filtreren die hun integratie nog in ontwikkeling of het testen hebben.
8. Wat gebeurt er als de integratie met een MVPD is uitgeschakeld en als inactief is gemarkeerd? configuration-phase-faq8
Wanneer de integratie met een MVPD is uitgeschakeld en als inactief is gemarkeerd, wordt de MVPD verwijderd uit de lijst met MVPD's die in verdere configuratieantwoorden wordt geleverd. Er zijn twee belangrijke gevolgen die in overweging moeten worden genomen:
- De niet-geverifieerde gebruikers van die MVPD kunnen de verificatiefase niet meer voltooien met die MVPD.
- De geverifieerde gebruikers van die MVPD kunnen de fase van voorafgaande toestemming, autorisatie of afmelding met die MVPD niet meer voltooien.
De cliënttoepassing zou een fout van de Authentificatie van Adobe Pass REST API V2 ontvangen als de gebruiker selecteerde MVPD geen actieve integratie met de gespecificeerde dienstverlener heeft.
9. Wat gebeurt er als de integratie met een MVPD weer ingeschakeld en gemarkeerd wordt als actief? configuration-phase-faq9
Wanneer de integratie met een MVPD terug en duidelijk als actief wordt toegelaten, dan is MVPD inbegrepen terug in de lijst van MVPDs die in verdere configuratiereacties wordt verstrekt, en er zijn twee belangrijke gevolgen om te overwegen:
- De niet-geverifieerde gebruikers van die MVPD kunnen de verificatiefase opnieuw voltooien met behulp van die MVPD.
- De geautoriseerde gebruikers van die MVPD kunnen de fase van voorafgaande toestemming, autorisatie of afmelding met die MVPD opnieuw voltooien.
10. Hoe kan de integratie met een MVPD worden in- of uitgeschakeld? configuration-phase-faq10
Deze verrichting kan door het Dashboard van Adobe Pass worden voltooid TVE door één van uw organisatiebeheerders of door een vertegenwoordiger van de Authentificatie van Adobe Pass handelend namens u.
Voor meer details, verwijs naar de documentatie van de Gebruiker van de Gids van de Integratie van het Dashboard van 0} TVE.
Veelgestelde vragen over de verificatiefase authentication-phase-faqs-general
1. Wat is het doel van de authentificatiefase? authentication-phase-faq1
Het doel van de authentificatiefase is de cliënttoepassing de capaciteit te verstrekken om de identiteit van de gebruiker te verifiëren en informatie van gebruikersmeta-gegevens te verkrijgen.
De verificatiefase fungeert als een noodzakelijke stap voor de fase voorafgaand aan autorisatie of de machtigingsfase wanneer de clienttoepassing inhoud moet afspelen.
2. Is de authenticatiefase verplicht? authentication-phase-faq2
De verificatiefase is verplicht. De clienttoepassing moet de gebruiker verifiëren wanneer deze geen geldig profiel heeft binnen de Adobe Pass-verificatie.
De cliënttoepassing kan deze fase in de volgende scenario's overslaan:
- De gebruiker is al geverifieerd en het profiel is nog steeds geldig.
- De gebruiker wordt aangeboden tijdelijke toegang door basis of promotionele eigenschap TempPass.
De fout behandeling van de cliënttoepassing vereist om de fout codes (b.v., authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, enz.) te behandelen, die erop wijzen dat de cliënttoepassing de gebruiker om vereist voor authentiek te verklaren.
3. Wat is een verificatiesessie en hoe lang is deze geldig? authentication-phase-faq3
De authentificatiesessie is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
De authentificatiesessie slaat informatie over het in werking gestelde authentificatieproces op dat van het eindpunt van Zittingen kan worden teruggewonnen.
De verificatiesessie is geldig gedurende een beperkt en kort tijdsbestek dat op het moment van uitgifte door de notAfter -tijdstempel wordt opgegeven. Dit geeft aan hoeveel tijd de gebruiker nodig heeft om het verificatieproces te voltooien voordat hij of zij de flow opnieuw moet starten.
De cliënttoepassing kan de reactie van de authentificatiesessie gebruiken om te weten hoe te met het authentificatieproces te werk te gaan. Let op: er zijn gevallen waarin de gebruiker niet verplicht is om te verifiëren, zoals het verlenen van tijdelijke toegang, gedegradeerde toegang, of wanneer de gebruiker reeds voor authentiek wordt verklaard.
Raadpleeg de volgende documenten voor meer informatie:
- API voor verificatiesessie maken
- API voor verificatiesessie hervatten
- Standaardverificatiestroom uitgevoerd binnen primaire toepassing
- Basisverificatiestroom uitgevoerd binnen secundaire toepassing
4. Wat is een verificatiecode en hoe lang is deze geldig? authentication-phase-faq4
De authentificatiecode is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
De authentificatiecode slaat een unieke waarde op die wordt geproduceerd wanneer een gebruiker het authentificatieproces in werking stelt, en identificeert uniek de authentificatiesessie van een gebruiker tot het proces volledig is of tot de authentificatiesessie verloopt.
De verificatiecode is geldig gedurende een beperkt en kort tijdsbestek dat is opgegeven op het moment dat de verificatiesessie wordt gestart met de notAfter -tijdstempel, om aan te geven hoeveel tijd de gebruiker nodig heeft om het verificatieproces te voltooien voordat hij of zij de flow opnieuw moet starten.
De clienttoepassing kan de verificatiecode gebruiken om te controleren of de gebruiker de verificatie heeft voltooid en om de profielgegevens van de gebruiker op te halen, meestal via een opiniepeilingsmechanisme.
De cliënttoepassing kan de authentificatiecode ook gebruiken om de gebruiker toe te staan om het authentificatieproces of op het zelfde apparaat of op tweede (scherm) te voltooien of te hervatten, aangezien de authentificatiesessie niet verstreek.
Raadpleeg de volgende documenten voor meer informatie:
- API voor verificatiesessie maken
- API voor verificatiesessie hervatten
- Standaardverificatiestroom uitgevoerd binnen primaire toepassing
- Basisverificatiestroom uitgevoerd binnen secundaire toepassing
5. Hoe kan de cliënttoepassing weten als de gebruiker een geldige authentificatiecode typte en dat de authentificatiesessie nog niet verliep? authentication-phase-faq5
De cliënttoepassing kan de authentificatiecode bevestigen die door de gebruiker in een secundaire (scherm) toepassing wordt getypt door een verzoek naar één van het eindpunt van Zittingen te verzenden verantwoordelijk om authentificatiesessie te hervatten of de informatie van de authentificatiesessie terug te winnen verbonden aan de authentificatiecode.
De cliënttoepassing zou een fout ontvangen als de verstrekte authentificatiecode verkeerd werd getypt of in het geval dat de authentificatiesessie zou verlopen.
Voor meer informatie, verwijs naar hervat authentificatiesessie en ontvang authentificatiesessie documenten.
6. Hoe kan de clienttoepassing weten of de gebruiker al is geverifieerd? authentication-phase-faq6
De cliënttoepassing kan één van de volgende eindpunten vragen geschikt om te verifiëren of een gebruiker reeds voor authentiek wordt verklaard en de informatie van het terugkeerprofiel terugkeert:
- API voor eindpunt van profielen
- Het eindpunt van profielen voor specifieke MVPD API
- Het eindpunt van profielen voor specifieke (authentificatie) code API
Raadpleeg de volgende documenten voor meer informatie:
- Stroom van basisprofielen uitgevoerd in primaire toepassing
- De stroom van basisprofielen die binnen secundaire toepassing wordt uitgevoerd
7. Wat is een profiel en hoe lang is het geldig? authentication-phase-faq7
Het profiel is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
Het profiel slaat informatie over de de authentificatierealiteit van de gebruiker, meta-gegevensinformatie en veel meer op die van het eindpunt van Profielen kunnen worden teruggewonnen.
De clienttoepassing kan het profiel gebruiken om de verificatiestatus van de gebruiker te kennen, toegang te krijgen tot metagegevens van de gebruiker, de methode te zoeken die wordt gebruikt voor verificatie of de entiteit die wordt gebruikt voor het opgeven van de identiteit.
Raadpleeg de volgende documenten voor meer informatie:
- API voor eindpunt van profielen
- Het eindpunt van profielen voor specifieke MVPD API
- Het eindpunt van profielen voor specifieke (authentificatie) code API
- Stroom van basisprofielen uitgevoerd in primaire toepassing
- De stroom van basisprofielen die binnen secundaire toepassing wordt uitgevoerd
Het profiel is geldig gedurende een beperkt tijdsbestek dat is opgegeven wanneer het wordt opgevraagd door het tijdstempel van notAfter . Dit geeft aan hoeveel tijd de gebruiker een geldige verificatie heeft voordat deze de verificatiefase opnieuw moet doorlopen.
Dit beperkte die tijdkader als authentificatie (authN) wordt bekend TTL kan door het Dashboard van Adobe Pass worden bekeken en worden veranderd TVE door één van uw organisatiebeheerders of door een vertegenwoordiger van de Authentificatie van Adobe Pass handelend namens u.
Voor meer details, verwijs naar de documentatie van de Gebruiker van de Gids van de Integratie van het Dashboard van 0} TVE.
8. Moet de clienttoepassing de profielgegevens van de gebruiker in cache plaatsen in een permanente opslag? authentication-phase-faq8
De clienttoepassing moet delen van de profielgegevens van de gebruiker in een permanente opslag in cache plaatsen om onnodige verzoeken te voorkomen en de gebruikerservaring te verbeteren, rekening houdend met de volgende aspecten:
| table 0-row-2 1-row-2 2-row-2 3-row-2 | |
|---|---|
| Kenmerk | Gebruikerservaring |
mvpd |
De clienttoepassing kan dit gebruiken om de geselecteerde tv-provider van de gebruiker bij te houden en deze verder te blijven gebruiken tijdens de fase voorafgaand aan autorisatie of autorisatie. wanneer het huidige gebruikersprofiel verloopt, kan de cliënttoepassing de onthouden selectie van MVPD gebruiken en enkel de gebruiker vragen om te bevestigen. |
attributes |
De cliënttoepassing kan dit gebruiken om de gebruikerservaring te personaliseren die op verschillende wordt gebaseerd gebruikersmeta-gegevens sleutels (b.v., zip, maxRating, enz.).de meta-gegevens van de Gebruiker wordt beschikbaar nadat de authentificatiestroom voltooit, daarom te hoeven de cliënttoepassing niet om een afzonderlijk eindpunt te vragen om de gebruiker meta-gegevens informatie terug te winnen, aangezien het reeds inbegrepen in de profielinformatie is. bepaalde meta-gegevensattributen kunnen tijdens de vergunningsstroom worden bijgewerkt, afhankelijk van MVPD en de specifieke meta-gegevensattributen. Hierdoor moet de clienttoepassing mogelijk opnieuw een query uitvoeren op de API's voor profielen om de meest recente metagegevens van gebruikers op te halen. |
notAfter |
De clienttoepassing kan dit gebruiken om de vervaldatum van het gebruikersprofiel bij te houden. de fout behandeling van de cliënttoepassing vereist om de fout codes (b.v., authenticated_profile_missing, authenticated_profile_expired, authenticated_profile_invalidated, enz.) te behandelen, die erop wijst dat de cliënttoepassing de gebruiker om vereist voor authentiek te verklaren. |
9. Kan de clienttoepassing het profiel van de gebruiker uitbreiden zonder dat opnieuw verificatie vereist is? authentication-phase-faq9
Nee.
Het gebruikersprofiel kan niet buiten zijn geldigheid zonder gebruikersinteractie worden uitgebreid, aangezien zijn vervaldatum door authentificatie TTL wordt bepaald die met MVPDs wordt gevestigd.
Daarom moet de clienttoepassing de gebruiker vragen opnieuw te verifiëren en te communiceren met de MVPD-aanmeldingspagina om het profiel op ons systeem te vernieuwen.
Nochtans, voor MVPDs die op huis-gebaseerde authentificatie (HBA) steunt, zal de gebruiker niet worden vereist om geloofsbrieven in te gaan.
10. Wat zijn de gebruiksgevallen voor elk beschikbaar eindpunt van Profielen? authentication-phase-faq10
De eindpunten van de Profielen van de basis worden ontworpen om cliënttoepassing het vermogen te verstrekken om de de authentificatiestatus van de gebruiker te kennen, tot de informatie van gebruikersmeta-gegevens toegang te hebben, de methode te vinden die wordt gebruikt om voor authentiek te verklaren of de entiteit die wordt gebruikt om identiteit te verstrekken.
Elk eindpunt past als volgt bij een specifiek geval van gebruik:
| table 0-row-3 1-row-3 2-row-3 3-row-3 | ||
|---|---|---|
| API | Beschrijving | Hoofdletters gebruiken |
| het eindpunt van Profielen API | Alle gebruikersprofielen ophalen. | Gebruiker opent de cliënttoepassing voor het eerst In dit scenario, heeft de cliënttoepassing niet het geselecteerde herkenningsteken van MVPD van de gebruiker in het voorgeheugen onder wordt gebracht in blijvende opslag. dientengevolge, zal het één enkel verzoek verzenden om alle beschikbare gebruikersprofielen terug te winnen. |
| eindpunt van Profielen voor specifieke MVPD API | Hiermee wordt het gebruikersprofiel opgehaald dat is gekoppeld aan een specifieke MVPD. | de terugkeer van de Gebruiker aan de cliënttoepassing na het voor authentiek verklaren in een vorig bezoek In dit geval, moet de cliënttoepassing het eerder geselecteerde herkenningsteken van MVPD van de gebruiker hebben in blijvende opslag in het voorgeheugen onder wordt gebracht. dientengevolge, zal het één enkel verzoek verzenden om het profiel van de gebruiker voor die specifieke MVPD terug te winnen. |
| eindpunt van Profielen voor specifieke (authentificatie) code API | Haal het gebruikersprofiel op dat is gekoppeld aan een specifieke verificatiecode. | Gebruiker stelt het authentificatieproces in dit scenario in werking, moet de cliënttoepassing bepalen of de gebruiker met succes authentificatie heeft voltooid en hun profielinformatie terugwinnen. dientengevolge, zal het een opiniepeilingsmechanisme beginnen om het profiel van de gebruiker terug te winnen verbonden aan de authentificatiecode. |
Voor meer details, verwijs naar de Basisprofielstroom die binnen primaire toepassing wordt uitgevoerd en Basisprofielstroom die binnen secundaire toepassing documenten wordt uitgevoerd.
Het eindpunt van Profielen SSO dient een verschillend doel, het verstrekt de cliënttoepassing het vermogen om een gebruikersprofiel tot stand te brengen gebruikend de reactie van de partnerauthentificatie en het terug te winnen in één enkele, éénmalige verrichting.
| table 0-row-3 1-row-3 | ||
|---|---|---|
| API | Beschrijving | Hoofdletters gebruiken |
| Profielen SSO eindpunt API | Creeer en wik gebruikersprofiel gebruikend de reactie van de partnerauthentificatie. | Gebruiker laat de toepassing toe om partner enig-sign-on te gebruiken om in dit scenario voor authentiek te verklaren, moet de cliënttoepassing een gebruikersprofiel tot stand brengen na het ontvangen van de reactie van de partnerauthentificatie en het in één enkele, eenmalige verrichting terugwinnen. |
Voor om het even welke verdere vragen, moeten de basis eindpunten van Profielen worden gebruikt om de de authentificatiestatus van de gebruiker te bepalen, tot de informatie van gebruikersmeta-gegevens toegang te hebben, de methode te vinden die wordt gebruikt om voor authentiek te verklaren of de entiteit die wordt gebruikt om identiteit te verstrekken.
Voor meer details, verwijs naar Enige sign-on gebruikend partnerstromen en Apple SSO Cookbook (REST API V2) documenten.
11. Wat moet de clienttoepassing doen als de gebruiker meerdere MVPD-profielen heeft? authentication-phase-faq11
Het besluit om meerdere profielen te ondersteunen hangt af van de zakelijke vereisten van de clienttoepassing.
De meeste gebruikers hebben slechts één profiel. Als er echter meerdere profielen zijn (zoals hieronder wordt beschreven), bepaalt de clienttoepassing de beste gebruikerservaring bij het selecteren van profielen.
De clienttoepassing kan de gebruiker vragen het gewenste MVPD-profiel te selecteren of de selectie automatisch te maken, bijvoorbeeld door het eerste gebruikersprofiel in het antwoord te kiezen of het profiel met de langste geldigheidsperiode.
REST API v2 biedt ondersteuning voor meerdere profielen om:
- Gebruikers die kunnen kiezen tussen een normaal MVPD-profiel en een profiel dat is verkregen via SSO (Single Sign-On).
- Gebruikers die tijdelijke toegang krijgen zonder dat ze zich hoeven af te melden bij hun normale MVPD.
- Gebruikers met een MVPD-abonnement in combinatie met DTC-services (Direct-to-Consumer).
- Gebruikers met meerdere MVPD-abonnementen.
12. Wat gebeurt er als gebruikersprofielen verlopen? authentication-phase-faq12
Wanneer gebruikersprofielen verlopen, worden ze niet meer opgenomen in de reactie van het eindpunt van Profielen.
Als het eindpunt van Profielen een lege reactie van de profielkaart terugkeert, moet de cliënttoepassing een nieuwe authentificatiesessie creëren en de gebruiker ertoe aanzetten om opnieuw voor authentiek te verklaren.
Voor meer informatie, verwijs naar creeer authentificatiesessie API documentatie.
13. Wanneer worden gebruikersprofielen ongeldig? authentication-phase-faq13
Gebruikersprofielen worden in de volgende gevallen ongeldig:
- Wanneer de verificatie-TTL verloopt, zoals aangegeven door het tijdstempel van
notAfterin de eindpuntreactie van Profielen. - Wanneer de cliënttoepassing AP-apparaat-Identifier kopbalwaarde verandert.
- Wanneer de cliënttoepassing de cliëntgeloofsbrieven bijwerkt die worden gebruikt om de kopbalwaarde van de Vergunning terug te winnen.
- Wanneer de clienttoepassing de softwarefunctie die wordt gebruikt om clientreferenties op te halen of bijwerkt.
14. Wanneer moet de clienttoepassing het opiniepeilingsmechanisme starten? authentication-phase-faq14
Om de efficiëntie te waarborgen en onnodige verzoeken te vermijden, moet de clienttoepassing onder de volgende omstandigheden beginnen met het opiniepeilingsmechanisme:
Authentificatie die binnen de primaire (scherm) toepassing wordt uitgevoerd
De primaire (het stromen) toepassing zou moeten beginnen opiniepeilend wanneer de gebruiker de definitieve bestemmingspagina bereikt, nadat de browser component URL laadt die voor de redirectUrl parameter in het 2} eindpuntverzoek van Sessies {wordt gespecificeerd.
Authentificatie die binnen een secundaire (scherm) toepassing wordt uitgevoerd
De primaire (het stromen) toepassing zou moeten beginnen opiniepeilend zodra de gebruiker het authentificatieproces-recht na het ontvangen van de eindpuntreactie van de Zittingen in werking stelt en de authentificatiecode aan de gebruiker toont.
15. Wanneer moet de clienttoepassing het opiniepeilingsmechanisme stoppen? authentication-phase-faq15
Om de efficiëntie te waarborgen en onnodige verzoeken te vermijden, moet de clienttoepassing het opiniepeilingsmechanisme stopzetten onder de volgende omstandigheden:
Succesvolle authentificatie
De profielgegevens van de gebruiker worden opgehaald en hun verificatiestatus wordt bevestigd. Op dit moment is opiniepeiling niet langer nodig.
de zitting van de Authentificatie en coderepering
De authentificatiesessie en de code verlopen, zoals die door notAfter wordt vermeld timestamp (b.v., 30 minuten) in de 2} eindpuntreactie van Zittingen {. Als dit gebeurt, moet de gebruiker het authentificatieproces opnieuw beginnen, en de opiniepeiling die de vorige authentificatiecode gebruikt zou onmiddellijk moeten worden tegengehouden.
Nieuwe geproduceerde authentificatiecode
Als de gebruiker om een nieuwe authentificatiecode op het primaire (scherm) apparaat verzoekt, is de bestaande zitting niet meer geldig, en de opiniepeiling die de vorige authentificatiecode gebruikt zou onmiddellijk moeten worden tegengehouden.
16. Welk interval tussen vraag zou de cliënttoepassing voor het opiniepeilingsmechanisme moeten gebruiken? authentication-phase-faq16
Om efficiëntie te garanderen en onnodige verzoeken te voorkomen, moet de clienttoepassing de frequentie van het opiniepeilingsmechanisme onder de volgende omstandigheden configureren:
| table 0-row-2 1-row-2 | |
|---|---|
| Authentificatie die binnen de primaire (scherm) toepassing wordt uitgevoerd | Authentificatie die binnen een secundaire (scherm) toepassing wordt uitgevoerd |
| De primaire (het stromen) toepassing zou om de 3-5 seconden of meer moeten opiniepeilen. | De primaire (het stromen) toepassing zou om de 3-5 seconden of meer moeten opiniepeilen. |
17. Wat is het maximumaantal opiniepeilingsverzoeken dat de clienttoepassing kan verzenden? authentication-phase-faq17
De cliënttoepassing moet de huidige grenzen naleven die door de Authentificatie van Adobe Pass worden bepaald die Mechanisme van de Omwenteling .
De fout behandeling van de cliënttoepassing moet 429 Te Vele de foutencode van Verzoeken kunnen behandelen, die erop wijst dat de cliënttoepassing het maximum toegestane aantal verzoeken heeft overschreden.
Voor meer details, verwijs naar het Throttling Mechanisme documentatie.
18. Hoe kan de clienttoepassing de metagegevens van de gebruiker ophalen? authentication-phase-faq18
De cliënttoepassing kan één van de volgende eindpunten vragen geschikt om informatie van gebruikersmeta-gegevens als deel van de profielinformatie terug te keren:
- API voor eindpunt van profielen
- Het eindpunt van profielen voor specifieke MVPD API
- Het eindpunt van profielen voor specifieke (authentificatie) code API
De meta-gegevens van de gebruiker worden beschikbaar nadat de authentificatiestroom voltooit, daarom te hoeven de cliënttoepassing geen afzonderlijk eindpunt vragen om de informatie van gebruikersmeta-gegevens terug te winnen, aangezien het reeds inbegrepen in de profielinformatie is.
Raadpleeg de volgende documenten voor meer informatie:
- Stroom van basisprofielen uitgevoerd in primaire toepassing
- De stroom van basisprofielen die binnen secundaire toepassing wordt uitgevoerd
Afhankelijk van de MVPD en het specifieke metagegevenskenmerk kunnen bepaalde metagegevenskenmerken tijdens de autorisatiestroom worden bijgewerkt. Hierdoor moet de clienttoepassing mogelijk opnieuw een query uitvoeren op de bovenstaande API's om de meest recente metagegevens van de gebruiker op te halen.
19. Hoe moet de clienttoepassing onbeheerde toegang beheren? authentication-phase-faq19
De Eigenschap van de Vermindering laat de cliënttoepassing toe om een naadloze het stromen ervaring voor gebruikers te handhaven, zelfs wanneer hun de authentificatie of toestemmingsdiensten van MVPD kwesties ontmoeten.
Samenvattend kan dit zorgen voor ononderbroken toegang tot inhoud ondanks verstoringen van de tijdelijke service van MVPD.
Aangezien uw organisatie van plan is om de functie van de premiedegradatie te gebruiken, moet de cliënttoepassing degraded toegangsstromen behandelen, die schetsen hoe REST API v2 eindpunten zich in dergelijke scenario's gedragen.
Voor meer details, verwijs naar Verminderde toegangsstromen documentatie.
20. Hoe moet de clienttoepassing tijdelijke toegang beheren? authentication-phase-faq20
De Eigenschap TempPass laat de cliënttoepassing toe om tijdelijke toegang tot de gebruiker te verlenen.
Samenvattend kan dit gebruikers in dienst nemen door gedurende een bepaalde periode beperkte toegang tot inhoud of een vooraf gedefinieerd aantal VOD-titels te bieden.
Aangezien uw organisatie van plan is de premiumfunctie TempPass te gebruiken, moet de clienttoepassing tijdelijke toegangsstromen afhandelen, die beschrijven hoe REST API v2-eindpunten zich in dergelijke scenario's gedragen.
In vorige API-versies moest de clienttoepassing zich afmelden bij een gebruiker die met zijn gewone MVPD was geverifieerd om tijdelijke toegang te bieden.
Met REST API v2 kan de clienttoepassing bij het autoriseren van een stream naadloos schakelen tussen een gewone MVPD en een TempPass MVPD, zodat de gebruiker zich niet hoeft af te melden.
Voor meer details, verwijs naar de Tijdelijke toegangsstromen documentatie.
21. Hoe moet de clienttoepassing apparaatoverschrijdende Single Sign-On-toegang beheren? authentication-phase-faq21
REST API v2 kan Single Sign-On voor meerdere apparaten inschakelen als de clienttoepassing een consistente unieke gebruikersidentificatie voor alle apparaten biedt.
Dit herkenningsteken, dat als dienstteken wordt bekend, moet door de cliënttoepassing door de implementatie of de integratie van een externe Dienst van de Identiteit van keus worden geproduceerd.
Voor meer details, verwijs naar Enige sign-on gebruikend de stromen van het de dienstteken documentatie.
Veelgestelde vragen over de preautorisatiefase preauthorization-phase-faqs-general
1. Wat is het doel van de fase van voorafgaande toestemming? preauthorization-phase-faq1
Het doel van de fase van voorafgaande toestemming is de clienttoepassing de mogelijkheid te bieden een subset van bronnen uit de catalogus te presenteren waartoe de gebruiker toegang zou hebben.
De fase voorafgaand aan autorisatie kan de gebruikerservaring verbeteren wanneer de gebruiker de cliënttoepassing voor het eerst opent of aan een nieuwe sectie navigeert.
2. Is de voorafgaande toelatingsfase verplicht? preauthorization-phase-faq2
De fase voorafgaand aan autorisatie is niet verplicht. De clienttoepassing kan deze fase overslaan als deze een catalogus met bronnen wil presenteren zonder deze eerst te filteren op basis van de machtiging van de gebruiker.
3. Wat is een voorafgaande beslissing? preauthorization-phase-faq3
Voortoestemming is een termijn die in de 1} documentatie van de Verklarende woordenlijst {wordt bepaald, terwijl de besluitvormingstermijn ook in de Verklarende woordenlijst kan worden gevonden.
In het voorafgaande goedkeuringsbesluit wordt informatie over het onderzoeksresultaat van het MVPD-proces voorafgaand aan de autorisatie opgeslagen die kan worden opgehaald uit het eindpunt van de Besluiten vooraf autoriseren.
De clienttoepassing kan de voorafgaande autorisatiebeslissingen gebruiken om een subset van bronnen weer te geven waartoe de gebruiker toegang heeft (informatieve) beslissingen van de tv-provider.
Raadpleeg de volgende documenten voor meer informatie:
- API voor beslissingen vóór autorisatie ophalen
- Basis preautorisatiestroom uitgevoerd binnen primaire toepassing
4. Moet de clienttoepassing de voorafgaande beslissingen in een permanente opslag in cache plaatsen? preauthorization-phase-faq4
De clienttoepassing is niet verplicht om beslissingen vóór autorisatie op te slaan in permanente opslag. Nochtans, wordt het geadviseerd om vergunningsbesluiten in het voorgeheugen op te slaan om de gebruikerservaring te verbeteren. Dit helpt onnodige vraag aan de Besluiten te vermijden vooraf goedkeurt eindpunt voor middelen die reeds zijn toegestaan, verminderend latentie en verbeterend prestaties.
5. Hoe kan de clienttoepassing bepalen waarom een besluit tot voorafgaande toestemming is geweigerd? preauthorization-phase-faq5
De cliënttoepassing kan de reden voor een ontkend pre-vergunningsbesluit bepalen door de foutencode en het bericht te inspecteren inbegrepen in de reactie van het Besluiten pre-goedkeurt eindpunt. Deze gegevens verschaffen insight de specifieke reden waarom het verzoek om voorafgaande toestemming is geweigerd, zodat de gebruiker op de hoogte wordt gebracht van de gebruikerservaring of de benodigde afhandeling in de toepassing wordt geactiveerd.
Ervoor zorgen dat elk nieuw mechanisme dat wordt toegepast voor het ophalen van beslissingen vóór toelating, niet in een eindeloze lus resulteert als het besluit vóór toelating wordt geweigerd.
U kunt overwegen om pogingen tot een redelijk aantal te beperken en weigeringen netjes af te handelen door duidelijke feedback aan de gebruiker te bekijken.
6. Waarom ontbreekt het aan een media-token in het besluit tot voorafgaande toestemming? preauthorization-phase-faq6
In het besluit tot voorafgaande toestemming ontbreekt een media-token omdat de fase van voorafgaande toestemming niet mag worden gebruikt om bronnen af te spelen, aangezien dat het doel is van de fase van autorisatie.
7. Kan de machtigingsfase worden overgeslagen als er al een besluit tot voorafgaande goedkeuring bestaat? preauthorization-phase-faq7
Nee.
De machtigingsfase kan niet worden overgeslagen, zelfs niet als er een besluit tot voorafgaande toestemming beschikbaar is. Voorafgaande beslissingen zijn alleen ter informatie en geven geen daadwerkelijke afspeelrechten. De fase voorafgaand aan de autorisatie is bedoeld als vroegtijdig advies, maar de fase van autorisatie is nog steeds vereist voordat inhoud wordt afgespeeld.
8. Wat is een bron en welke indelingen worden ondersteund? preauthorization-phase-faq8
Het middel is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
De bron is een unieke id die is overeengekomen met MVPD's en die is gekoppeld aan inhoud die de clienttoepassing kan streamen.
De unieke resource-id kan twee indelingen hebben:
- Een eenvoudige tekenreeksindeling, zoals een unieke id voor een kanaal (merk).
- Een media RSS-indeling (MRSS) met aanvullende informatie, zoals de titel, classificaties en metagegevens voor ouderlijk toezicht.
Voor meer details, verwijs naar de Beschermde documentatie van Middelen .
9. Voor hoeveel middelen kan de clienttoepassing tegelijkertijd een besluit tot voorafgaande toestemming verkrijgen? preauthorization-phase-faq9
De clienttoepassing kan een voorafgaande autorisatiebeslissing voor een beperkt aantal bronnen verkrijgen in één API-aanvraag, meestal maximaal 5, als gevolg van voorwaarden die door de MVPD's worden opgelegd.
Dit maximumaantal middelen kan worden bekeken en veranderd na het akkoord gaan met MVPDs door het Dashboard van Adobe Pass TVE door één van uw organisatiebeheerders of door een vertegenwoordiger van de Authentificatie van Adobe Pass handelend namens u.
Voor meer details, verwijs naar de documentatie van de Gebruiker van de Gids van de Integratie van het Dashboard van 0} TVE.
Veelgestelde vragen over de machtigingsfase authorization-phase-faqs-general
1. Wat is het doel van de machtigingsfase? authorization-phase-faq1
Het doel van de machtigingsfase is om de clienttoepassing de mogelijkheid te bieden om bronnen af te spelen die de gebruiker vraagt nadat hij zijn rechten met de MVPD heeft gevalideerd.
2. Is de machtigingsfase verplicht? authorization-phase-faq2
De autorisatiefase is verplicht, de clienttoepassing kan deze fase niet overslaan als deze bronnen wil afspelen die de gebruiker vraagt, omdat deze eerst met de MVPD moet controleren of de gebruiker gerechtigd is voordat de stream wordt vrijgegeven.
3. Wat is een vergunningsbesluit en hoe lang is het geldig? authorization-phase-faq3
De vergunning is een termijn die in de 1} documentatie van de Verklarende woordenlijst {wordt bepaald, terwijl de besluitvormingstermijn ook in de Verklarende woordenlijst kan worden gevonden.
In het vergunningsbesluit wordt informatie over het onderzoeksresultaat van het MVPD-autorisatieproces opgeslagen die kan worden opgehaald uit het eindpunt van de Besluiten Autoriseren.
De clienttoepassing kan het machtigingsbesluit met een media-token gebruiken om de bronstream af te spelen voor het geval de gebruiker toegang zou krijgen tot de stream als het besluit van de tv-provider (gezaghebbend) dat besluit zou bevatten.
Raadpleeg de volgende documenten voor meer informatie:
- API voor goedkeuringsbeslissingen ophalen
- Basisvergunningsstroom uitgevoerd binnen primaire toepassing
Het vergunningsbesluit is geldig voor een beperkte en korte periode die op het ogenblik van afgifte wordt gespecificeerd, die op de hoeveelheid tijd wijst het door de Authentificatie van Adobe Pass zal worden in het voorgeheugen ondergebracht alvorens te vereisen om de MVPD opnieuw te vragen.
Dit beperkte die tijdkader als vergunning (authZ) wordt bekend TTL kan door het Dashboard van Adobe Pass worden bekeken en worden veranderd TVE door één van uw organisatiebeheerders of door een vertegenwoordiger van de Authentificatie van Adobe Pass handelend namens u.
Voor meer details, verwijs naar de documentatie van de Gebruiker van de Gids van de Integratie van het Dashboard van 0} TVE.
4. Moet de clienttoepassing de vergunningsbesluiten in een permanente opslag in cache plaatsen? authorization-phase-faq4
De clienttoepassing is niet verplicht om machtigingsbesluiten op te slaan in permanente opslag.
5. Hoe kan de clienttoepassing bepalen waarom een vergunningsbesluit is geweigerd? authorization-phase-faq5
De cliënttoepassing kan de reden voor een ontkend vergunningsbesluit bepalen door de foutencode en het bericht te inspecteren inbegrepen in de reactie van Besluiten machtigt eindpunt. Deze gegevens verschaffen insight de specifieke reden waarom de aanvraag voor een vergunning is afgewezen, zodat de gebruiker op de hoogte kan worden gebracht van de ervaring of een noodzakelijke afhandeling van de toepassing kan worden gestart.
Ervoor zorgen dat een nieuw mechanisme dat wordt toegepast voor het ophalen van vergunningsbesluiten niet in een eindeloze lus resulteert als het vergunningsbesluit wordt geweigerd.
U kunt overwegen om pogingen tot een redelijk aantal te beperken en weigeringen netjes af te handelen door duidelijke feedback aan de gebruiker te bekijken.
6. Wat is een media-token en hoe lang is het geldig? authorization-phase-faq6
Het media teken is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
Het media token bestaat uit een ondertekende tekenreeks die in duidelijke tekst wordt verzonden en die kan worden opgehaald uit het eindpunt Autoriseren van beslissingen.
Voor meer informatie, verwijs naar de Symbolische documentatie van de Verificateur van Media .
De mediatoken is geldig gedurende een beperkte en korte periode die op het moment van uitgifte is opgegeven. Deze periode geeft de tijdslimiet aan voordat deze door de clienttoepassing moet worden geverifieerd en gebruikt.
De clienttoepassing kan het media-token gebruiken om een bronstream af te spelen voor het geval dat de gebruiker toegang zou krijgen tot de stream als de beslissing van de tv-provider (gezaghebbend).
Raadpleeg de volgende documenten voor meer informatie:
- API voor goedkeuringsbeslissingen ophalen
- Basisvergunningsstroom uitgevoerd binnen primaire toepassing
7. Moet de clienttoepassing het media-token valideren voordat de bronstream wordt afgespeeld? authorization-phase-faq7
Ja.
De clienttoepassing moet het mediatoken valideren voordat de bronstream wordt afgespeeld. Deze bevestiging zou moeten worden uitgevoerd gebruikend de Symbolische Verifier van Media . Door serializedToken van de geretourneerde token te controleren, helpt de clienttoepassing onbevoegde toegang te voorkomen, zoals het rippen van streams, en zorgt deze ervoor dat alleen correct geautoriseerde gebruikers de inhoud kunnen afspelen.
8. Moet de clienttoepassing een verlopen mediatken vernieuwen tijdens het afspelen? authorization-phase-faq8
Nee.
De clienttoepassing is niet verplicht een verlopen mediatoken te vernieuwen terwijl de stream actief wordt afgespeeld. Als het media-token tijdens het afspelen verloopt, moet het zijn toegestaan dat de stream zonder onderbreking wordt voortgezet. Nochtans, moet de cliënt om een nieuw vergunningsbesluit verzoeken — en een nieuw media teken verkrijgen — de volgende tijd de gebruiker probeert om een middel te spelen.
9. Wat is het doel van elk tijdstempelkenmerk in het vergunningsbesluit? authorization-phase-faq9
Het vergunningsbesluit bevat verschillende tijdstempelkenmerken die een essentiële context bieden voor de geldigheidsperiode van de vergunning zelf en de bijbehorende media-token. Deze tijdstempels hebben verschillende doeleinden, afhankelijk van het feit of ze betrekking hebben op het vergunningsbesluit of het media-token.
besluit-Niveau Tijdstempels
Deze tijdstempels beschrijven de geldigheidsperiode van het algemene vergunningsbesluit:
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Kenmerk | Beschrijving | Notities |
notBefore |
De tijd in milliseconden waarop het vergunningsbesluit is genomen. | Dit is het begin van het geldigheidvenster van de autorisatie. |
notAfter |
De tijd in milliseconden wanneer het vergunningsbesluit verloopt. | De toestemmingstijd-aan-Levende (TTL) bepaalt hoe lang de vergunning geldig blijft alvorens re-vergunning te vereisen. Over deze GVTO wordt onderhandeld met vertegenwoordigers van MVPD. |
symbolisch-Niveau Tijdstempels
Deze tijdstempels beschrijven de geldigheidsperiode van het media-token dat aan het vergunningsbesluit is gekoppeld:
| table 0-row-3 1-row-3 2-row-3 | ||
|---|---|---|
| Kenmerk | Beschrijving | Notities |
notBefore |
De tijd in milliseconden toen het media teken werd uitgegeven. | Dit geeft aan wanneer het token geldig wordt voor afspelen. |
notAfter |
De tijd in milliseconden wanneer het media teken verloopt. | De tokens van media hebben een opzettelijk korte levensduur (typisch 7 minuten) om misgebruikrisico's te minimaliseren en voor potentiële klokverschillen tussen de symbolisch-genererende server en de symbolisch-controlerende server rekening te houden. |
10. Wat is een bron en welke indelingen worden ondersteund? authorization-phase-faq10
Het middel is een termijn die in de verklarende woordenlijst documentatie wordt bepaald.
De bron is een unieke id die is overeengekomen met MVPD's en die is gekoppeld aan inhoud die de clienttoepassing kan streamen.
De unieke resource-id kan twee indelingen hebben:
- Een eenvoudige tekenreeksindeling, zoals een unieke id voor een kanaal (merk).
- Een media RSS-indeling (MRSS) met aanvullende informatie, zoals de titel, classificaties en metagegevens voor ouderlijk toezicht.
Voor meer details, verwijs naar de Beschermde documentatie van Middelen .
11. Voor hoeveel middelen kan de clienttoepassing tegelijkertijd een vergunningsbesluit verkrijgen? authorization-phase-faq11
De cliënttoepassing kan een vergunningsbesluit voor een beperkt aantal middelen in één enkel API verzoek, gewoonlijk tot 1, wegens voorwaarden verkrijgen die door MVPDs worden opgelegd.
Veelgestelde vragen over de afmeldingsfase logout-phase-faqs-general
1. Wat is het doel van de afmeldingsfase? logout-phase-faq1
Het doel van de afmeldingsfase is om de clienttoepassing de mogelijkheid te bieden het geverifieerde profiel van de gebruiker binnen de Adobe Pass-verificatie op verzoek te beëindigen.
2. Is de afmeldingsfase verplicht? logout-phase-faq2
De afmeldingsfase is verplicht. De clienttoepassing moet de gebruiker de mogelijkheid bieden zich af te melden.
Veelgestelde vragen over kopteksten headers-faqs-general
1. Hoe kan de waarde voor de machtigingsheader worden berekend? headers-faq1
| note important |
|---|
| IMPORTANT |
Als de clienttoepassing migreert van REST API V1 naar REST API V2, kan de clienttoepassing dezelfde methode blijven gebruiken om de waarde van het toegangstoken van Bearer te verkrijgen als voorheen. |
De verzoekkopbal van de Vergunning 0} {bevat het toegangstoken dat door de cliënttoepassing wordt vereist om tot Adobe Pass beschermde APIs toegang te hebben.Bearer
De headerwaarde voor autorisatie moet worden verkregen bij Adobe Pass-verificatie tijdens de registratiefase.
Raadpleeg de volgende documenten voor meer informatie:
- Overzicht van dynamische clientregistratie
- Client credentials-API ophalen
- API voor toegangstoken ophalen
- Dynamic Client Registration Flow
2. Hoe kan ik de waarde voor de kop van de AP-Device-Identifier berekenen? headers-faq2
| note important |
|---|
| IMPORTANT |
| Als de clienttoepassing migreert van REST API V1 naar REST API V2, kan de clienttoepassing dezelfde methode blijven gebruiken om de waarde van de apparaat-id te berekenen zoals voorheen. |
De AP-Apparaat-Herkenningsteken verzoekkopbal bevat het stromen apparatenherkenningsteken aangezien het door de cliënttoepassing werd gecreeerd.
De AP-Apparaat-Herkenningsteken kopbaldocumentatie verstrekt voorbeelden voor belangrijke platforms van hoe te om de waarde gegevens te verwerken, maar de cliënttoepassing kan verkiezen om een verschillende methode te gebruiken die op zijn eigen bedrijfslogica en vereisten wordt gebaseerd.
3. Hoe kan ik de waarde voor de X-Device-Info header berekenen? headers-faq3
| note important |
|---|
| IMPORTANT |
| Als de clienttoepassing migreert van REST API V1 naar REST API V2, kan de clienttoepassing dezelfde methode blijven gebruiken om de waarde van de apparaatinformatie te berekenen als voorheen. |
De x-apparaat-Info verzoekkopbal bevat de cliëntinformatie (apparaat, verbinding en toepassing) met betrekking tot het daadwerkelijke het stromen apparaat en wordt gebruikt om platform-specifieke regels te bepalen die MVPDs kan afdwingen.
De x-apparaat-Info kopbaldocumentatie verstrekt voorbeelden voor belangrijke platforms van hoe te om de waarde gegevens te verwerken, maar de cliënttoepassing kan verkiezen om een verschillende methode te gebruiken die op zijn eigen bedrijfslogica en vereisten wordt gebaseerd.
Als x-apparaat-Info kopbal mist of onjuiste waarden bevat, kan het verzoek als voortkomend van een unknown platform worden geclassificeerd.
Dit kan ertoe leiden dat het verzoek als onveilig wordt behandeld, en onderworpen aan meer beperkende regels, zoals kortere authentificatie TTLs. Bovendien, zijn sommige gebieden, zoals het stromen apparaat connectionIp en connectionPort, verplicht voor eigenschappen zoals de Authentificatie van de Basis van het Spectrum .
Zelfs wanneer het verzoek uit een server namens een apparaat voortkomt, moet de x-apparaat-Info kopbalwaarde op de daadwerkelijke het stromen apparateninformatie wijzen.
Diverse veelgestelde vragen misc-faqs-general
1. Kan ik de REST API V2-verzoeken en -antwoorden verkennen en de API testen? misc-faq1
Ja.
U kunt REST API V2 door onze specifieke Adobe Developer website onderzoeken. De Adobe Developer-website biedt onbeperkte toegang tot:
Om met REST API V2 in wisselwerking te staan, moet u de 3} kopbal van de Vergunning {met a toegangstoken omvatten dat via Bearer wordt verkregen DCR API .
Voor het gebruiken van DCR API , wordt een softwareverklaring met REST API V2 werkingsgebied vereist. Voor meer details, verwijs naar het Dynamische document van Veelgestelde vragen van de Registratie van de Cliënt (DCR) .
2. Kan ik de REST API V2-verzoeken en -antwoorden verkennen met behulp van een API-ontwikkelingsprogramma met OpenAPI-ondersteuning? misc-faq2
Ja.
U kunt OpenAPI specificatiedossiers voor DCR API en REST API V2 van de Adobe Developer website downloaden.
Als u de specificatiebestanden van OpenAPI wilt downloaden, klikt u op de downloadknoppen om de volgende bestanden op te slaan op uw lokale computer:
U kunt deze bestanden vervolgens importeren in uw voorkeursprogramma voor API-ontwikkeling om de REST API V2-verzoeken en -antwoorden te verkennen en de API te testen.
3. Kan ik nog steeds het bestaande API-testprogramma gebruiken dat zich bevindt op https://sp.auth-staging.adobe.com/apitest/api.html? misc-faq3
Nee.
De clienttoepassingen die migreren naar REST API V2 moeten het nieuwe testprogramma gebruiken dat zich bevindt op https://developer.adobe.com/adobe-pass/. De Adobe Developer-website biedt onbeperkte toegang tot:
Om met REST API V2 in wisselwerking te staan, moet u de 3} kopbal van de Vergunning {met a toegangstoken omvatten dat via Bearer wordt verkregen DCR API .
Voor het gebruiken van DCR API , wordt een softwareverklaring met REST API V2 werkingsgebied vereist. Voor meer details, verwijs naar het Dynamische document van Veelgestelde vragen van de Registratie van de Cliënt (DCR) .
Veelgestelde vragen over migratie migration-faqs
Ga verder met deze sectie als u werkt aan een toepassing die een bestaande toepassing moet migreren naar REST API V2.
Algemene veelgestelde vragen over migratie general-migration-faqs
1. Moet ik een nieuwe clienttoepassing implementeren die naar REST API V2 is gemigreerd voor alle gebruikers tegelijk? migration-faq1
Nee.
De clienttoepassing is niet verplicht een nieuwe versie uit te voeren waarin de REST API V2 wordt geïntegreerd voor alle gebruikers tegelijk.
Adobe Pass Authentication zal tot eind 2025 oudere versies van clienttoepassingen blijven ondersteunen waarin de REST API V1 of SDK zijn geïntegreerd.
2. Moet ik een nieuwe clienttoepassing implementeren die is gemigreerd naar REST API V2 voor alle API's en die tegelijkertijd stromen? migration-faq2
Ja.
De clienttoepassing is vereist om een nieuwe versie uit te voeren die de REST API V2 integreert voor alle Adobe Pass Authentication-API's en die tegelijkertijd stroomt.
In het geval van de "tweede het schermauthentificatie"stroom, wordt de cliënttoepassing vereist om een nieuwe versie uit te voeren die REST API V2 voor zowel de primaire als secundaire toepassingen gelijktijdig integreert.
Adobe Pass Authentication biedt geen ondersteuning voor 'hybride' implementaties waarbij zowel REST API V2 als REST API V1/SDK worden geïntegreerd tussen API's en stromen.
3. Zal de gebruikersverificatie behouden blijven bij het bijwerken naar een nieuwe clienttoepassing die is gemigreerd naar REST API V2? migration-faq3
Nee.
De gebruikersverificatie die is verkregen in oudere clienttoepassingsversies waarin de REST API V1 of SDK is geïntegreerd, blijft niet behouden.
Daarom moet de gebruiker opnieuw worden geverifieerd in de nieuwe clienttoepassing die is gemigreerd naar REST API V2.
4. Zijn de verbeterde foutcodes standaard ingeschakeld in REST API V2? migration-faq4
Ja.
De clienttoepassingen die migreren naar REST API V2 profiteren standaard automatisch van deze functie, waardoor gedetailleerdere en nauwkeurige foutinformatie wordt geboden.
Voor meer details, verwijs naar de Verbeterde documentatie van de Codes van de Fout .
5. Vergen bestaande integraties configuratiewijzigingen wanneer wordt gemigreerd naar REST API V2? migration-faq5
Nee.
De clienttoepassingen die migreren naar REST API V2, vereisen geen configuratiewijzigingen voor bestaande MVPD-integratie. Ook, zullen zij de zelfde herkenningstekens voor bestaande dienstverleners en blijven gebruiken MVPDs .
Bovendien, blijven de protocollen die door de Authentificatie van Adobe Pass worden gebruikt om met eindpunten van MVPD te communiceren onveranderd.
Migratie van REST API V1 naar REST API V2 migration-rest-api-v1-to-rest-api-v2-faqs
Ga verder met deze subsectie als u werkt aan een toepassing die van REST API V1 naar REST API V2 moet migreren.
Veelgestelde vragen over de registratiefase registration-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Welke API-migraties op hoog niveau zijn vereist voor de registratiefase? registration-phase-v1-to-v2-faq1
Bij de migratie van REST API V1 naar REST API V2 zijn er geen wijzigingen op hoog niveau met betrekking tot de registratiefase.
De cliënttoepassing kan de zelfde stroom blijven gebruiken om tegen de Authentificatie van Adobe Pass door het Dynamische proces van de Registratie van de Cliënt (DCR) te registreren en een toegangstoken te verkrijgen.
Raadpleeg de volgende documenten voor meer informatie:
Veelgestelde vragen over de configuratiefase configuration-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Wat zijn de API-migraties op hoog niveau die vereist zijn voor de configuratiefase? configuration-phase-v1-to-v2-faq1
Bij de migratie van REST API V1 naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabel worden vermeld:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | REST API V1 | REST API V2 | Opmerkingen |
| Lijst met MVPD's met actieve integratie ophalen | GET /api/v1/config/{serviceProvider} |
GET /api/v2/{serviceProvider}/configuration |
Veelgestelde vragen over de verificatiefase authentication-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Wat zijn de API-migraties op hoog niveau die vereist zijn voor de verificatiefase? authentication-phase-v1-to-v2-faq1
Bij de migratie van REST API V1 naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabel worden vermeld:
| 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 | |||
|---|---|---|---|
| Toepassingsgebied | REST API V1 | REST API V2 | Opmerkingen |
| Registratiecode ophalen (verificatiecode) | POST /reggie/v1/{serviceProvider}/regcode |
POST /api/v2/{serviceProvider}/zittingen |
Raadpleeg de volgende documenten voor meer informatie: |
| Registratiecode controleren (verificatiecode) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider} /essies/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Verificatie hervatten (MVPD) op tweede scherm (toepassing) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider} /essies/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| (MVPD) verificatie starten | GET /api/v1/authenticate |
GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Gebruikersverificatiestatus controleren | GET /api/v1/checkauthn (eerste scherm) GET /api/v1/checkauthn (tweede scherm) |
Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Verificatietoken van gebruiker ophalen (profiel) | GET /api/v1/tokens/authn |
Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Metagegevens van gebruikers ophalen | GET /api/v1/tokens/usermetadata |
Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de preautorisatiefase preauthorization-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Welke API-migraties op hoog niveau zijn vereist voor de fase voorafgaand aan de autorisatie? preauthorization-phase-v1-to-v2-faq1
Bij de migratie van REST API V1 naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabel worden vermeld:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | REST API V1 | REST API V2 | Opmerkingen |
| Voorkeursmiddelen ophalen (voorafgaande autorisatiebesluiten) | GET /api/v1/preauthorize (eerste scherm) GET /api/v1/preauthorize (tweede scherm) |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de machtigingsfase authorization-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Welke API-migraties op hoog niveau zijn vereist voor de machtigingsfase? authorization-phase-v1-to-v2-faq1
Bij de migratie van REST API V1 naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabel worden vermeld:
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | REST API V1 | REST API V2 | Opmerkingen |
| Autorisatie (MVPD) starten | GET /api/v1/authorize |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Token van autorisatie ophalen (machtigingsbesluit) | GET /api/v1/tokens/authz |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Token voor korte autorisatie ophalen (mediatoken) | GET /api/v1/tokens/media |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de afmeldingsfase logout-phase-faqs-migration-rest-api-v1-to-rest-api-v2
1. Wat zijn de API-migraties op hoog niveau die vereist zijn voor de afmeldingsfase? logout-phase-v1-to-v2-faq1
Bij de migratie van REST API V1 naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabel worden vermeld:
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | REST API V1 | REST API V2 | Opmerkingen |
| Afmelden starten | GET /api/v1/logout |
GET /api/v2/{serviceProvider}/logout |
Raadpleeg de volgende documenten voor meer informatie: |
Migratie van SDK naar REST API V2 migration-sdk-to-rest-api-v2
Ga verder met deze subsectie als u werkt aan een toepassing die van SDK naar REST API V2 moet migreren.
Veelgestelde vragen over de registratiefase registration-phase-faqs-migration-sdk-to-rest-api-v2
1. Welke API-migraties op hoog niveau zijn vereist voor de registratiefase? registration-phase-sdk-to-v2-faq1
Bij de migratie van SDK's naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabellen worden voorgesteld:
AccessEnabled JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Complete Dynamic Client Registration (DCR) | Softwareinstructie leveren aan constructor | POST /o/client/register GET /o/client/token |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Complete Dynamic Client Registration (DCR) | Softwareinstructie leveren aan constructor | POST /o/client/register GET /o/client/token |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabled Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Complete Dynamic Client Registration (DCR) | Softwareinstructie leveren aan constructor | POST /o/client/register GET /o/client/token |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Complete Dynamic Client Registration (DCR) | Softwareinstructie leveren aan constructor | POST /o/client/register GET /o/client/token |
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de configuratiefase configuration-phase-faqs-migration-sdk-to-rest-api-v2
1. Wat zijn de API-migraties op hoog niveau die vereist zijn voor de configuratiefase? configuration-phase-sdk-to-v2-faq1
Bij de migratie van SDK's naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabellen worden voorgesteld:
AccessEnabled JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Lijst met MVPD's met actieve integratie ophalen | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Lijst met MVPD's met actieve integratie ophalen | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabled Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Lijst met MVPD's met actieve integratie ophalen | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Lijst met MVPD's met actieve integratie ophalen | AccessEnabler.getAuthentication | GET /api/v2/{serviceProvider}/configuration |
Veelgestelde vragen over de verificatiefase authentication-phase-faqs-migration-sdk-to-rest-api-v2
1. Wat zijn de API-migraties op hoog niveau die vereist zijn voor de verificatiefase? authentication-phase-sdk-to-v2-faq1
Bij de migratie van SDK's naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabellen worden voorgesteld:
AccessEnabled JavaScript SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| (MVPD) verificatie starten | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Gebruikersverificatiestatus controleren | AccessEnabler.checkAuthentication | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Metagegevens van gebruikers ophalen | AccessEnabler.getMetadata | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabled iOS SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| (MVPD) verificatie starten | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Gebruikersverificatiestatus controleren | AccessEnabler.checkAuthentication | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Metagegevens van gebruikers ophalen | AccessEnabler.getMetadata | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler tvOS SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Registratiecode ophalen (verificatiecode) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen |
Raadpleeg de volgende documenten voor meer informatie: |
| Registratiecode controleren (verificatiecode) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider} /essies/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Verificatie hervatten (MVPD) op tweede scherm (toepassing) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider} /essies/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| (MVPD) verificatie starten | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Gebruikersverificatiestatus controleren | AccessEnabler.checkAuthentication | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Metagegevens van gebruikers ophalen | AccessEnabler.getMetadata | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabled Android SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| (MVPD) verificatie starten | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Gebruikersverificatiestatus controleren | AccessEnabler.checkAuthentication | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Metagegevens van gebruikers ophalen | AccessEnabler.getMetadata | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 2-row-4 3-row-4 4-row-4 5-row-4 6-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Registratiecode ophalen (verificatiecode) | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen |
Raadpleeg de volgende documenten voor meer informatie: |
| Registratiecode controleren (verificatiecode) | GET /reggie/v1/{serviceProvider}/regcode/{code} |
GET /api/v2/{serviceProvider} /essies/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Verificatie hervatten (MVPD) op tweede scherm (toepassing) | GET /api/v1/authenticate |
POST /api/v2/{serviceProvider} /essies/{code} GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| (MVPD) verificatie starten | AccessEnabler.getAuthentication AccessEnabler.setSelectedProvider |
POST /api/v2/{serviceProvider}/zittingen GET /api/v2/authenticate/{serviceProvider}/{code} |
Raadpleeg de volgende documenten voor meer informatie: |
| Gebruikersverificatiestatus controleren | AccessEnabler.checkAuthentication | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
| Metagegevens van gebruikers ophalen | AccessEnabler.getMetadata | Voer een van de volgende handelingen uit: GET /api/v2/{serviceProvider}/profiles GET /api/v2/{serviceProvider}/profiles/{mvpd} GET /api/v2/{serviceProvider}/profiles/code/{code} |
De clienttoepassing kan de reactie van deze API's voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de preautorisatiefase preauthorization-phase-faqs-migration-sdk-to-rest-api-v2
1. Welke API-migraties op hoog niveau zijn vereist voor de fase voorafgaand aan de autorisatie? preauthorization-phase-sdk-to-v2-faq1
Bij de migratie van SDK's naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabellen worden voorgesteld:
AccessEnabled JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Voorkeursmiddelen ophalen (voorafgaande autorisatiebesluiten) | AccessEnabler.checkPreauthorisedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Voorkeursmiddelen ophalen (voorafgaande autorisatiebesluiten) | AccessEnabler.checkPreauthorisedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabled Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Voorkeursmiddelen ophalen (voorafgaande autorisatiebesluiten) | AccessEnabler.checkPreauthorisedResources AccessEnabler.preauthorize |
POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Raadpleeg de volgende documenten voor meer informatie: |
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Voorkeursmiddelen ophalen (voorafgaande autorisatiebesluiten) | AccessEnabler.checkPreauthorisedResources | POST /api/v2/{serviceProvider}/decisions/preauthorize/{mvpd} |
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de machtigingsfase authorization-phase-faqs-migration-sdk-to-rest-api-v2
1. Welke API-migraties op hoog niveau zijn vereist voor de machtigingsfase? authorization-phase-sdk-to-v2-faq1
Bij de migratie van SDK's naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabellen worden voorgesteld:
AccessEnabled JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Token voor korte autorisatie ophalen (mediatoken) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Token voor korte autorisatie ophalen (mediatoken) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabled Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Token voor korte autorisatie ophalen (mediatoken) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Token voor korte autorisatie ophalen (mediatoken) | AccessEnabler.checkAuthorization AccessEnabler.getAuthorization |
POST /api/v2/{serviceProvider} /decisions/authorize/{mvpd} |
De clienttoepassing kan de reactie van deze API voor meerdere doeleinden tegelijk gebruiken:
Raadpleeg de volgende documenten voor meer informatie: |
Veelgestelde vragen over de afmeldingsfase logout-phase-faqs-migration-sdk-to-rest-api-v2
1. Wat zijn de API-migraties op hoog niveau die vereist zijn voor de afmeldingsfase? logout-phase-sdk-to-v2-faq1
Bij de migratie van SDK's naar REST API V2 zijn er belangrijke wijzigingen die in de volgende tabellen worden voorgesteld:
AccessEnabled JavaScript SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Afmelden starten | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler iOS/tvOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Afmelden starten | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabled Android SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Afmelden starten | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Raadpleeg de volgende documenten voor meer informatie: |
AccessEnabler FireOS SDK
| table 0-row-4 1-row-4 | |||
|---|---|---|---|
| Toepassingsgebied | SDK | REST API V2 | Opmerkingen |
| Afmelden starten | AccessEnabler.logout | GET /api/v2/{serviceProvider}/logout |
Raadpleeg de volgende documenten voor meer informatie: |