Användarmetadata user-metadata
Introduktion intro
Funktionen för användarmetadata gör att programmerare kan komma åt olika typer av användarspecifika data som hanteras av programmeringsgränssnitt. Metadatatyper för användare omfattar postnummer, föräldrabetyg, användar-ID med mera. Metadata för användare är ett tillägg till tidigare tillgängliga statiska-metadata (TTL för autentiseringstoken, TTL för auktoriseringstoken och enhets-ID).
Nyckelpunkter för användarmetadata:
- Skickades till programmerarens program under autentiserings- och auktoriseringsflödena
- Värden sparas i token
- Värdena kan normaliseras om olika PDF-filer tillhandahåller data i olika format
- Vissa parametrar kan krypteras med programmerarens nyckel (t.ex. postnummer)
- Specifika värden är tillgängliga av Adobe via en konfigurationsändring
Hämta användarmetadata obtaining
Användarmetadata är tillgängliga för programmerare via AccessEnabler getMetadata()
-funktionen och via /usermetadata
-slutpunkten i det klientlösa API:t. Mer information om hur du använder getMetadata()
och dess motsvarande återanrop setMetadataStatus()
finns i dokumentationen för plattforms-API (eller för slutpunkterna och parametrarna som används i det klientlösa API:t).
Programmerare får metadata genom att ange en nyckel för den typ av metadata som de vill hämta: getMetadata(key)
.
Metadata returneras enligt följande: setMetadataStatus(key, encrypted, data)
:
key
encrypted
data
Dataparameterns struktur, värdena varierar mellan olika typer:
zip
householdID
userID
maxRating
VCHIP: "X",
URL: "http://manage.my/parental" }
userID
userID
från householdID
.channelID
is_hoh
encryptedZip
typeID
primaryOID
typeID
är primär innehåller värdet för userID
Viktigt! De faktiska användarmetadata som är tillgängliga för en programmerare beror på vad ett MVPD-program gör tillgängligt. Juridiska avtal måste undertecknas med distributörer av videoprogrammeringstjänster innan känsliga användarmetadata (t.ex. postnummer) görs tillgängliga i produktionsmiljön.
Kraschen i det här fallet utfördes av historiska orsaker
Detta ID kan vara ett hushåll-ID eller ett underkonto-ID. Detta är vanligtvis inte angivet, det är bara det ID som är knutet till inloggningen som användes vid tidpunkten (vilket kan vara ett primärt eller ett underkonto)
ID:t kan även innehålla principer för övervakning av samtidig användning
För de flesta programmeringsgränssnitten är det här värdet lika med användar-ID:t
Det används ibland som ersättning för Föräldrakontroll om det inte finns några verkliga klassificeringar (om användaren var inloggad med hushållskontot kan han/hon titta på, annars visas inte klassificerat innehåll)
Det finns många variationer i flera sidopaneler för hur detta visas - hushållets användar-ID, huvud för hushåll-ID, huvud för hushållets flagga osv.
Typ-ID = Flagga som identifierar om användarkontot är primärt/sekundärt konto
Primärt OID = Hushållsidentifierare. Om TypeID är Primary innehåller värdet för userID
Har MPAA- eller VCHIP-klassificeringar
Observera att preflight-auktorisering i allmänhet ger större flexibilitet för den här användningen och bör användas i stället
OLCA-specifikationen tillåter detta som en AttributeStatement i AuthN-svaret
Kan även tillhandahållas med AuthZ-svaret för snabba uppdateringar
Känsliga data, kräver juridiska avtal för MVPD
Tillgängliga metadata available_metadata
I följande tabell visas det aktuella tillståndet för användarens metadata i Adobe Pass Authentication-ekosystemet:
Agreement
Signerat (endast zip)
på AuthN
i AuthN/Z
på AuthN/Z
ID för AuthN/Z
userID
zip
maxRating
householdID
channelID
2. För AuthZ - Det finns inget generiskt sätt eftersom auktoriseringsimplementeringen är MVPD-specifik
Detta är ett generiskt stöd för Synacor - kanske inte har lagts till i alla deras MVPD-program.
MVPD
För alla PDF-filer är användar-ID tillgängligt utan extra arbete.
Listan över användarmetadatatyper utökas allt eftersom nya typer blir tillgängliga och läggs till i Adobe Pass autentiseringssystem.
Kodexempel code_samples
Kodexempel 1 code_sample1
// Assuming a reference to the AccessEnabler has been previously obtained and stored in the "ae" variable
ae.setRequestor("SITE");
ae.checkAuthentication();
function setAuthenticationStatus(status, reason) {
if(status ==1) {
// User is authenticated, request metadata
ae.getMetadata("zip");
ae.getMetadata("maxRating");
} else {
...
}
}
// Implement the setMetadataStatus() callback
function setMetadataStatus(key, encrypted, data) {
if(encrypted) {
// The metadata value is encrypted
// Needs to be decrypted by the programmer
data = decrypt(data);
}
alert(key + "=" + data);
}
Code Sample 2 (Mock getMetadata) code_sample2
// Assuming a reference to the AccessEnabler has been
// previously obtained and stored in the "ae" variable
// Mock the getMetadata() method
var aeMock = {
getMetadata: function(key) {
var data = null;
// Set mock data based on the received key,
// according to the format in the spec
switch(key) {
case 'zip':
data = [ "1235", "23456" ];
break;
case 'maxRating':
data = { "MPAA": "PG-13", "VCHIP": "TV-14" };
break;
default:
break;
}
// Call the metadata status just like AccessEnabler does
setMetadataStatus(key, false, data);
}
}
ae.setRequestor("SITE");
ae.checkAuthentication();
function setAuthenticationStatus(status, reason) {
if (status == 1) {
// User is authenticated, request metadata using mock object
aeMock.getMetadata("zip");
aeMock.getMetadata("maxRating");
} else {
...
}
}
// Implement the setMetadataStatus() callback
function setMetadataStatus(key, encrypted, data) {
if (encrypted) {
// The metadata value is encrypted, so it
// needs to be decrypted by the programmer
data = decrypt(data);
}
alert(key + "=" + data);
}