Vermeiden Sie die Verwendung von '&'reg_code in /authenticate request clientless-avoid-using-reg_code-in-authenticate-request
Problem
Der IE 9-Browser interpretiert "\®"als speziellen Befehl und konvertiert ihn in ®.
Erklärung
Wenn die Variable /authenticate -Anfrage stellt sich wie folgt zusammen:
<FQDN>authenticate? requestor_id=someRequestor®_code=EKAFMFI&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.html
… wird es vom IE-Browser wie unten interpretiert und in diesem Format an Adobe gesendet:
<FQDN>authenticate?requestor_id=someRequestor®_code=EKAFMFI&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.html
Der Anforderer_id wird als univision®_code=EKAFMFI interpretiert, da es kein "&"gibt und Adobe keine regCode param , um das Token zuzuordnen. Es besteht die Möglichkeit, dass das AuthN-Token überhaupt nicht erstellt wird. In diesem Fall /checkauthn -Aufrufe können keine Token finden.
Lösung
Eine der folgenden Optionen sollte dieses Problem beheben:
-
Vermeiden Sie die Verwendung der
®_code-Parameter zwischen den anderen Abfragezeichenfolgen-Parametern. Verschieben Sie sie stattdessen in den ersten Abfragezeichenfolgenparameter in der Anforderungs-URL, sodass die Anforderungs-URL wie folgt lautet:code language-none <fqdn>authenticate?reg_code =EKAFMFI&requestor_id=someRequestor&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.htmlAuf diese Weise wird die
®param wird nicht falsch interpretiert. -
Normalisieren
®_codeVerwendung&reg_code. -
Adobe könnte eine neue Funktion einführen, mit der ein Fehlercode als Reaktion auf einen Authentifizierungsaufruf an den zweiten Bildschirm zurückgesendet werden kann, falls die AuthN-Token-Erstellung fehlgeschlagen ist.