In some contexts when you try to access the consent page or the .../device/user page in an OAuth2 flow you get a blank page; if you run a http trace you will see traces containing .html.js, such as:
This happens when there is a LB/site with port 80 or 443 and for which the port is removed when trying to access the html file. This affects only 13.0.x as it is linked to the text.js file (located in /XUI/libs)
Set OpenAM on port 8080: http://openam.example.com:8080/openam
Create a OAuth2 provider
Create a site on port 80: http://lb.example.com:80/openam
Add the server to the site
The result is a blank page; in the trace you can see the snippet above.
The issue is that the port 80 is stripped from the URL. You can fix it in one of the following ways:
1) Make sure the URL always contains the port (fix at LB level)
2) Modify the Base URL source for the realm (add the service to the realm) and select "Fixed value" then populate Fixed value base URL: with http://lb.example.com/openam (without the port). Configuring the load balancer to send X-Forwarded-Proto and X-Forwarded-Host headers would be another option.
Drawback of this is that you will always have to access OpenAM through the load balancer and not through the server directly; it may not be an applicable/convenient solution.
3) Modify the file .../XUI/libs/text.js and replace the line: