I have a WebAdaptor set up at a non-standard Port 447. A ReverseProxy and the Portal's WebContext-URL are configured as well. When accessing the Portals /home/ Page, all reqeusts are routed correctly. But after Login, some resources are requestes with port 7443 included. Here is my setup:
I followed the documentation (https://enterprise.arcgis.com/de/portal/latest/administer/windows/use-a-non-default-port-for-the-por... and at some point after Login a resource is requested using the internal portal port:
https://reverseproxy.domain.com:7443/arcgisportal/sharing/rest/portals/self/subscriptionInfo?f=json
This happens in the base.js --> getSecureUrl function. For some reason the property esriGeowConfig.self.httpsPort is set to 7443. The property location.hostname is set to the reverseproxy. When that method is entered, the given url is just fine:
https://reverseproxy.domain.com/arcgisportal/sharing/rest/portals/self/subscriptionInfo
Within that method that if-statement basically does this:
b = b.replace(location.hostname, location.hostname + ":" + esriGeowConfig.self.httpsPort)
As result, the url is returned as
https://reverseproxy.domain.com:7443/arcgisportal/sharing/rest/portals/self/subscriptionInfo
Note: I do have another webadaptor running on webserver.internal.com which uses the default port 443. As expected, everything works fine. (I need those two webadaptors, because I have one set up for IWA and the other for anonymous access).
Hey Marc,
do you have the portal's WebContextURL set to https://reverseproxy.domain.com/arcgisportal ?
Yes, WebContextUrl is set to https://reverseproxy.domain.com/arcgisportal
And when accessing via WebAdaptor 1 which is running on the default port, all requests are using the reverse proxy and default port 443.
This is how the WebAdaptors are registered in portaladmin -> system -> webadaptors:
WebAdaptor 1 (port 443) is registered as follows:
Machine name: webserver.internal.com
Machine IP: 172.27.11.118
URL: https://webserver.internal.com/arcgisportal
Description:
HTTP port: 80
HTTPS port: 443
WebAdaptor 2 (port 447) is registered as follows:
Machine name: webserver.internal.com
Machine IP: 172.27.11.118
URL: https://webserver.internal.com:447/arcgisportal
Description:
HTTP port: 80
HTTPS port: 447
I wonder if the problem is you are using the same context "arcgisportal" for two different web adaptors on the same server and this is causing some confusion. When a request comes via the :447 WA the Portal doesn't recognise it as coming from its known WebContextURL, so redirects and responds with its internal :7443 address.
Unfortunately, I don't know what would repair that - perhaps add https://webserver.internal.com:447/arcgisportal to the redirects list allowed for the portal (go to sharing/rest/self - run getAppID for "arcgisonline", then run updateAppID and include the URL with :447)
As a test, I did unregister WebAdaptor 1 (port 443). Having only one registered WebAdaptor (port 447) did not fix the issue.
I also tried to have both Webadaptors running on port 443 with different context-names (webserver.internal.com/arcgisportal1 and webserver.internal.com/arcgisportal2). Then, I don't get any port-issues, but context-issues instead. E.g., some URLs now include the Webadaptors context-name instead of what is expected at the reverse proxy: https://reverseproxy.domain.com/arcgisportal1/sharing/rest/...
Adding the webadaptor host with the specific port 447 to the list of redirectURIs did not solve the problem, either.
Have you confirmed the reverse proxy is setting the X-Forwarded-Host header (if layer 7) before passing the request to the Web Adaptor target? Are you using a non-default port in the WebContextURL portal system property?
Reference Doc: https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-...
The WebContextUrl property uses the default port 443: https://reverseproxy.domain.com/arcgisportal
I have no access to the reverse proxy configuration, but according to the Admininstrator the X-Forwarded-Host header is set. I asked for the specific configuration of the X-Forwarded-Host header and the Location Headers in order to double check. Maybe the FQDN of the GIS-Portal-Server and the reverse proxy server have been mixed up.