Client occasionally hangs at "Getting configuration...." when app is otherwise fine for other users

[cd-rite]

This can sometimes persist through a refresh of the page, requiring closing browser windows and reopening to resolve...
Some overly-persistent browser caching?
Happens after the redirect from keycloak.

Issue can be recreated (transiently) when request to /user does not respond
Or occasionally when token request fails with invalid pkce verifier

To even investigate, we'll need some changes to client init to provide more granular or informative error messages about the stage the process is at.

[cannonist]

After updating to the latest version of stig-manager, I get the following error instead of the previous "Getting configuration...": "C"Authorizing {"error":"invalid_grant","error_description":"PKCE verification failed"}".

It happens pretty frequently so I'm looking to fix this problem, but feel providing information might be a better method of getting there as I'm running out of ideas. If my situation can contribute to understanding or fixing the problem, I'm more than willing to share more details or perform additional tests.

Environment:

• OS: RHEL 8
• Podman version: 4.9.4-rhel
• Podman-compose version: 1.0.6
• Keycloak version: 26.0.7
• Nginx version: 1.27.3
• Mysql version: 8.4.3-1.el9
• STIG-manager version: latest

Steps taken:

• Run podman compose up
• Navigate to stig-manager through the proxy pass
• Redirect to stigman realm login, sign in and receive {"error":"invalid_grant","error_description":"PKCE verification failed"}

Logs:

• The main error events from Keycloak and Stigman:

  [auth] | 2024-12-20 19:01:11,762 WARN [org.keycloak.events] (executor-thread-2) type=CODE_TO_TOKEN_ERROR, realmId=stigman, clientId=stig-manager, userId=76da8a88-fb48-4477-a920-d88a6b8747fa, ipAddress=10.89.16.143, error=pkce_verification_failed, grant_type=authorization_code, code_id=cf6ffb8d-bef8-4510-9f76-362a292f4c10, client_auth_method=client-secret
  [stigman] | {"date":"2024-12-20T19:01:12.726Z","level":3,"component":"static","type":"transaction","data":{"request":{"date":"2024-12-20T19:01:12.725Z","source":"::ffff:10.90.0.138","method":"GET","url":"/serviceWorker.js","headers":{"host":"stigman:54000","connection":"close","user-agent":"Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0","accept":"/","accept-language":"en-US,en;q=0.5","accept-encoding":"gzip, deflate, br, zstd","service-worker":"script","sec-fetch-dest":"serviceworker","sec-fetch-mode":"same-origin","sec-fetch-site":"same-origin","if-modified-since":"Sat, 14 Dec 2024 20:47:14 GMT","if-none-match":"W/"4e4-193c6ece450"","priority":"u=4","cache-control":"max-age=0","authorization":false}},"response":{"date":"2024-12-20T19:01:12.726Z","status":304,"headers":{"x-powered-by":"Express","access-control-allow-origin":"*","accept-ranges":"bytes","cache-control":"public, max-age=0","last-modified":"Sat, 14 Dec 2024 20:47:14 GMT","etag":"W/"4e4-193c6ece450""},"responseBody":""},"operationStats":{"durationMs":1}}}

• stigman-logs_access-error.txt

  • Shows the startup process for all containers (nginx, auth, db, stigman). I've attached the full stdout during 'podman compose up' and attempt to connect to stig-manager.

• stigman-logs_access-successful.txt

  • After leaving the same orchestration up for a while, I can sometimes successfully get into stig-manager without hitting the previous error. This seems more random.

Additional details:

• This persists through a refresh of the page, however upon refresh I run into a separate "502 bad gateway" error that fails to get represented in logs. It fixes when the user's token runs out, or gets signed out from KC. Perhaps it's an issue with how I've configured nginx, but I haven't been able to figure it out.
• It happens regardless of if I've cleared cookies.
• The issue, as best as I can tell, is related to the OIDC authentication flow between stig-manager and Keycloak.
• When using the previous stig-manager version, 1.4.19, I would successfully log into stig-manager the first time with all subsequent attempts failing despite the state of the browser. Bringing the compose down, and then back up again would make the orchestration "usable". This no longer works with the latest version of stig-manager.