[GH-ISSUE #567] Invalid OIDC endpoint causes Rust panic #9732

Closed
opened 2026-05-08 14:50:20 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @atakiya on GitHub (May 31, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/567

Unsure if this would be a bug report or feature request or something else entirely..

So if Komodo at startup cannot set up OIDC correctly when enabled per config, a certain code path that calls unwrap() causes the entire application to panic.
I do not think Komodo should be designed like this - in my instance I have both GitHub and a self-hosted OIDC provider set up. As long as at least one way to authenticate is available, it should simply disable them.
Alternatively, config option to make sure they are all available or vice versa?

Here's the Rust error just for clarity:

core-1  |
core-1  | thread 'tokio-runtime-worker' panicked at bin/core/src/auth/oidc/client.rs:54:6:
core-1  | called `Result::unwrap()` on an `Err` value: Failed to initialize OIDC client.
core-1  |
core-1  | Caused by:
core-1  |     0: Failed to get OIDC /.well-known/openid-configuration
core-1  |     1: Server returned invalid response: HTTP status code 400 Bad Request at https://auth.example.com/.well-known/openid-configuration
core-1  | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
core-1  | Error: task 3 panicked with message "called `Result::unwrap()` on an `Err` value: Failed to initialize OIDC client.\n\nCaused by:\n    0: Failed to get OIDC /.well-known/openid-configuration\n    1: Server returned invalid response: HTTP status code 400 Bad Request at https://auth.example.com/.well-known/openid-configuration"

For the reason why I encountered this error: I'm moving some subdomains around and currently my OIDC provider only returns 400s. Yes this is on me, but I assumed I could still use Komodo and log in via the GitHub IdP or username+password instead of plucking around in the CLI more.

In the case this is intended design, I'd like to understand why exactly.

Originally created by @atakiya on GitHub (May 31, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/567 Unsure if this would be a bug report or feature request or something else entirely.. So if Komodo at startup cannot set up OIDC correctly when enabled per config, a certain code path that calls `unwrap()` causes the entire application to panic. I do not think Komodo should be designed like this - in my instance I have both GitHub and a self-hosted OIDC provider set up. As long as **at least one** way to authenticate is available, it should simply disable them. Alternatively, config option to make sure they are all available or vice versa? Here's the Rust error just for clarity: ```Rust core-1 | core-1 | thread 'tokio-runtime-worker' panicked at bin/core/src/auth/oidc/client.rs:54:6: core-1 | called `Result::unwrap()` on an `Err` value: Failed to initialize OIDC client. core-1 | core-1 | Caused by: core-1 | 0: Failed to get OIDC /.well-known/openid-configuration core-1 | 1: Server returned invalid response: HTTP status code 400 Bad Request at https://auth.example.com/.well-known/openid-configuration core-1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace core-1 | Error: task 3 panicked with message "called `Result::unwrap()` on an `Err` value: Failed to initialize OIDC client.\n\nCaused by:\n 0: Failed to get OIDC /.well-known/openid-configuration\n 1: Server returned invalid response: HTTP status code 400 Bad Request at https://auth.example.com/.well-known/openid-configuration" ``` For the reason why I encountered this error: I'm moving some subdomains around and currently my OIDC provider only returns 400s. Yes this is on me, but I assumed I could still use Komodo and log in via the GitHub IdP or username+password instead of plucking around in the CLI more. In the case this is intended design, I'd like to understand why exactly.
GiteaMirror added the done label 2026-05-08 14:50:20 -05:00
Author
Owner

@mbecker20 commented on GitHub (Jun 7, 2025):

good point, its not necessary to panic in this case. It should just disable the oidc provider as an option and still allow alternatives

<!-- gh-comment-id:2953214398 --> @mbecker20 commented on GitHub (Jun 7, 2025): good point, its not necessary to panic in this case. It should just disable the oidc provider as an option and still allow alternatives
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/komodo#9732