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.
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.