Data Node: Cached basic auth credentials cause problems after completed preflight mode

[thll]

Expected Behavior

After completing datanode setup in the preflight mode, the Graylog UI should be fully functional without requiring to close and re-open the browser.

Current Behavior

After completing datanode setup in preflight mode, the browser automatically presents the Graylog login. After logging in as an admin user, the UI appears to work but has subtle failures: the input counter doesn't work and trying to open any of the node details pages on system/nodes fails with an error.

Possible Solution

I noticed that along with the auth cookie, the browser sends an Authorization header containing the basic auth credentials from preflight mode with every request to the backend. It looks like as if the backend treats the cookie with precedence when it authenticates the request, so we are logged in as the correct user. However, when a request is a "proxied request", i.e. it triggers secondary calls by the receiving node to other nodes in the cluster, the Authorization header is consulted.

We should make sure that we use the same source of authentication for both first-hand and proxied calls. Also, if it would be possible to clear the basic auth credentials from the browser cache, that would also be beneficial. However to my understanding this might be tricky.

This piece of code might be worth looking at: https://github.com/Graylog2/graylog2-server/blob/36ea21727f34aa19c9a9f9de4983d5a5d64e122d/graylog2-server/src/main/java/org/graylog2/shared/rest/resources/ProxiedResource.java#L111

Steps to Reproduce (for bugs)

1. Start a new cluster and complete preflight mode.
2. Log into Graylog without closing the browser.
3. Observe above mentioned irregularities.

Your Environment

• Graylog Version: 5.2.0-beta.3 (Docker)
• Java Version:
• OpenSearch Version:
• MongoDB Version:
• Operating System:
• Browser version:

[janheise]

We know the moment when we move from preflight to regular startup, and we also use two different basic realms. I wonder if clearing cached tokens in the backend at this point would force the browser (because of a different basic realm in the 401) to drop the currently used credentials and ask for new ones - or if your description of the problem already proves that this is not working.

[dennisoelkers]

@janheise: The underlying problem here is caused by core, actually. The order of precedence for basic auth info vs. session cookie is different between our general auth logic and the logic in proxied/clustered resources. #16999 should fix this.