Use [[ and ]] instead of [ and ] has been discussed to death... please use [[, unless you have a good reason (which you should call out... you're going to get this feedback every time)

I don't think this is right. Can you update your test plan to include registering / logging in / playing around with / refreshing the app? (Also the landing page)

You're missing a proxy config. I have no idea how you got this to work. Worries me that your test plan was incomplete

Feedback has not been addressed...

if the basePath is the same as the baseRoutePath, then you don't need the proxy pass for different routes.

I don't follow what you're talking about here. It seems to reflect a misunderstanding about what proxy does.

I think what happened is that you found proxy was not necessary during testing, and then you went ahead and made some assumptions about what it does instead of diving deeper to understand what's going on.

I usually don't have time to do a deep-dive in the code to clarify misconceptions, but in this case I wrote the code and I can take a second to help you out. In the future, it's my expectation that you'll be able to do this sort of "deep-dive" on your own.

Let's start by answering the question, "What does "proxy": "none": do?" You seem to have the perception that it decides whether to set up a "proxy pass", but that's not quite accurate.

A good way to understand what something does it git grep. Here's what I see when I run git grep in keyserver:

ashoat@ashoatmbp2021 [~/src/comm/keyserver]$ git grep proxy
src/session/cookies.js:  const { proxy } = getAppURLFactsFromRequestURL(req.originalUrl);
src/session/cookies.js:  if (proxy === 'none') {
src/session/cookies.js:  } else if (proxy === 'apache') {
src/utils/security-utils.js:  const { https, proxy } = getAppURLFactsFromRequestURL(req.originalUrl);
src/utils/security-utils.js:    (proxy === 'none' && req.protocol !== 'https') ||
src/utils/security-utils.js:    (proxy === 'apache' && req.get('X-Forwarded-SSL') !== 'on')
src/utils/urls.js:  +proxy?: 'apache' | 'none', // defaults to apache
src/utils/urls.js:    const { proxy } = urlFacts;
src/utils/urls.js:      proxy: validProxies.has(proxy) ? proxy : 'apache',

Let's look three all three of these files:

1. In the first file, getRequestIPAddress seems to use the proxy config to decide where to get the requester's IP address from. If proxy is set to apache, then we look for the X-Forwarded-For header. Otherwise, we just use the default req.socket.remoteAddress from Node.
2. In the second file, assertSecureRequest seems to use the proxy config to figure out whether the requester is using HTTPS. If proxy is set to apache, then we look for the X-Forwarded-SSL header. Otherwise, we just the default req.protocol === 'https' from Node.
3. The third file doesn't actually use proxy... it's just plumbing code for the config. So we can conclude it's irrelevant.

Now that we've looked at the code, we can start to understand more about proxy and why it matters. Now we have two questions to answer:

1. What does proxy do for landing? Why doesn't it seem to have any impact during testing?
2. What should landing_url.json contain?

For the first question, we can see clearly in the second file that https: false means that code doesn't even look at proxy. As for the first file, the getRequestIPAddress function is called from three places: fetchViewerForSocket, fetchViewerForJSONRequest, and fetchViewerForHomeRequest. None of these three callsites are accessed by the landing code in keyserver, so that explains the behavior you saw.

Next, let's ask "what should landing_url.json contain?" We can answer this by considering what proxy is meant to do.

1. First, we can observe that the default is Apache. The third file in our git grep above confirms that. We can ask ourselves "are we using an Apache proxy here?" If the answer is no, we probably should avoid this default.
2. Next, we can ask ourselves "is it possible that this config will be used by landing code in the future?" Here again I think the answer is "definitely yes"... if at any point the landing page needs to know the requester's IP address, it will need proxy to be correctly configured.

With this we can confidently conclude that you need to make a change here.

This isn't valid

Yea, sorry was still waking up