Select to view content in your preferred language

Hosting Server /login URL issue,

586
1
05-13-2024 08:42 AM
Labels (1)
AdamDrackley
Frequent Contributor

Hey everyone, hope things are well.  I had a quick question for anyone who might have run into this issue, or a similar one.  We have a Federated 10.9.1 ArcGIS Enterprise system with a standalone deployment of Experience Builder running on port :3000 on a different domain.  Occasionally, when we include Enterprise-hosted services in our ExB apps, we'll see the app receiving a 302 Found for a service call to these services, with the Response Headers containing the typical "Location" header to send the app off to authenticate against a URL similar to: "https://<PortalURL>/hosting/login?returnUrl=<ServiceUrl>.  

The app will then follow the redirect URL.  The issue is that the URL is actually incorrect; When the browser follows that redirect, they'll get another 302 Found with a Location header directing them to https://<PortalURL>/hosting/login/?returnUrl=<ServiceUrl>, coming from the Web Adapter.  Note the trailing slash after "/login".  Because the URL doesn't take the client to ArcGIS Server, just to the Web Adapter which provides the next redirect, ArcGIS Server isn't providing the typical auto-CORS header which tells the browser that the requesting domain is friendly, so the CORS request refuses to follow the 302 and fails.

The issue is that, because the /login URL isn't real, Chrome will spring a CORS error and refuse to follow the second 302 redirect to the provided Location.

My question is; Is the /login URL configurable in the Enterprise config store, so I can add the appropriate slash?  Has anyone else run into this issue, or have a way to tell the Web Adapter to allow CORS requests against the "fake" /hosting/login URL so that browsers will follow the redirect to the "correct" /hosting/login/ URL?  Any thoughts folks could provide would be appreciated, many thanks.

1 Reply
AdamDrackley
Frequent Contributor

Just a note that the slash issue ended up being a red herring, because the fundamental problem was that the Identity Manager in Experience Builder was intermittently invalidating the tokens it would successfully generate to access secured services.  I found that by commenting out/removing the line "this.onSessionChanged($S.ArcGISJSSync)" in jimu-core/index.js, the tokens would no longer get invalidated when the Javascript API tries to procure a token (not sure offhand why this happens).  It's a workaround solution if anyone encounters this in the future, though if there's a more elegant solution than a code change let me know.

0 Kudos