(Legacy) Avoid Using '&'reg_code in /authenticate Request clientless-avoid-using-reg_code-in-authenticate-request
Issue
The IE 9 browser interprets ‘®â€™ as a special command and converts it to ®.
Explanation
If the /authenticate request is composed as follows…
<FQDN>authenticate? requestor_id=someRequestor®_code=EKAFMFI&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.html
…it will be interpreted by IE browser like below and will be sent to 51ºÚÁϲ»´òìÈ in this format:
<FQDN>authenticate?requestor_id=someRequestor®_code=EKAFMFI&domain_name=someRequestor.com&noflash=true&mso_id=someMvpd&redirect_url=someRequestor.redirect.url.html
The requestor_id will be interpreted as univision®_code=EKAFMFI, since there is no ‘&’, and 51ºÚÁϲ»´òìÈ will not find a regCode param to associate the token with. There is a chance that the AuthN token will not be created at all, in which case /checkauthn calls will fail to find any tokens.
Solution
One of the following options should solve this issue:
-
Avoid using the
®_codeparam between the other query string params. Instead move it to the first query-string parameter in the request URL, making the request url like this: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.htmlIn this way, the
®param will not be interpreted incorrectly. -
Normalize
®_codeas using&reg_code. -
51ºÚÁϲ»´òìÈ could introduce a new feature to send an error code back to the 2nd screen in response to an authentication call, if the AuthN token creation failed.