Undvik att använda '&'reg_code i /authenticate Request clientless-avoid-using-reg_code-in-authenticate-request
Problem
Webbläsaren IE 9 tolkar '&reg' som ett specialkommando och konverterar det till ®.
Förklaring
Om /authenticate-begäran består av följande…
<FQDN>authenticate? requestor_id=someRequestor®_code=EKAFMFI&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.html
…den tolkas av IE:s webbläsare som nedan och skickas till Adobe i detta format:
<FQDN>authenticate?requestor_id=someRequestor®_code=EKAFMFI&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.html
Begärande_id tolkas som univision®_code=EKAFMFI, eftersom det inte finns något '&', och Adobe kommer inte att hitta någon regCode-param att associera token med. Det finns en risk för att AuthN-token inte skapas alls. I så fall kan /checkauthn anrop inte hitta några token.
Lösning
Ett av följande alternativ bör lösa problemet:
-
Undvik att använda parametern
®_codemellan de andra frågesträngsparametrarna. Flytta den i stället till den första frågesträngsparametern i begärande-URL:en så här:code language-none <FQDN>authenticate?reg_code =EKAFMFI&requested_id=someRequestor&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.htmlPå så sätt kommer parametern
®inte att tolkas felaktigt. -
Normalisera
®_codesom om&reg_codeanvänds. -
Adobe kan introducera en ny funktion för att skicka tillbaka en felkod till den andra skärmen som svar på ett autentiseringsanrop, om det inte gick att skapa AuthN-token.