## Problem/Opportunity Statement Problem: when clicking "Add ACCESS account" on jetstream2.exosphere.app, it tries to navigate the browser to port 5000. This doesn't work on wifi networks that block outbound connections on port 5000 (such as UA guest WiFi). Attempted troubleshooting: config.js on prod, removed the ":5000" from `keystoneAuthUrl` in `openIdConnectLoginConfig`: ``` openIdConnectLoginConfig: { keystoneAuthUrl: "https://js2.jetstream-cloud.org:5000/identity/v3", ``` This fixed the problem with the login process, but then Exosphere would try to make an API call to get the Keystone regions, specifying port 443 in the HTTP request header to the Cloud CORS Proxy, and get a Horizon page (HTML) as the response, rather than a Keystone API response. (The correct behavior would be to pass port 5000 so that the CCP connects to Keystone.) So, I reverted the change to `config.js`. Instead, I compiled Exosphere with this patch and hand-deployed it to prod: ``` diff --git a/src/Page/LoginOpenIdConnect.elm b/src/Page/LoginOpenIdConnect.elm index af9caf6d..285f7da4 100644 --- a/src/Page/LoginOpenIdConnect.elm +++ b/src/Page/LoginOpenIdConnect.elm @@ -73,7 +73,9 @@ view context _ model = , onPress = let url = - model.keystoneAuthUrl ++ model.webssoKeystoneEndpoint + model.keystoneAuthUrl + ++ model.webssoKeystoneEndpoint + |> String.replace ":5000" "" in Just <| SharedMsg.LinkClicked <| Browser.External url } ``` This fixed the issue: afterward, people could complete the login process, select regions, and use Exosphere. (We successfully ran a Jetstream2 workshop an hour later, with some participants on a wifi network that blocks port 5000.) But this is a temporary workaround that will we will overwrite on the next prod deployment, so we should figure out what's going on and fix it. ~~It's possible something regressed after we fixed https://gitlab.com/jetstream-cloud/project-mgt/-/issues/54 .~~ ## What would success / a fix look like? We should figure out what's going on and fix it.