Describe the bug
When Keycloak authentication is enabled, the operator continues to checks session availability by probing the public session root URL without providing any authentication credentials.
The public URL is gated by oauth2-proxy, which when a unauthenticated request reaches it, it redirects the request to the Keycloak login page and returns status 200, which the operator marks as ready.
As a result, the operator does not verify whether the Theia application itself is ready to serve traffic. The operator following the oauth2-proxy redirect causes it to mark the session as ready but the underlying problem is that the operator availability check is unauthenticated.
Expected behavior
For auth enabled sessions I would expect the operator to continue to verify the readiness of the Theia application itself.
Cluster provider
No response
Version
No response
Additional information
If the probe is intentionally meant only to verify that the public URL, ingress, and oauth2-proxy are reachable, then this may be better classified as a feature request for the operator probe to verify an application-readiness signal.
In that case, I would be happy for this issue to be relabelled accordingly, or to recreate it as a feature request if preferred. 🙂
Describe the bug
When Keycloak authentication is enabled, the operator continues to checks session availability by probing the public session root URL without providing any authentication credentials.
The public URL is gated by oauth2-proxy, which when a unauthenticated request reaches it, it redirects the request to the Keycloak login page and returns status 200, which the operator marks as ready.
As a result, the operator does not verify whether the Theia application itself is ready to serve traffic. The operator following the oauth2-proxy redirect causes it to mark the session as ready but the underlying problem is that the operator availability check is unauthenticated.
Expected behavior
For auth enabled sessions I would expect the operator to continue to verify the readiness of the Theia application itself.
Cluster provider
No response
Version
No response
Additional information
If the probe is intentionally meant only to verify that the public URL, ingress, and oauth2-proxy are reachable, then this may be better classified as a feature request for the operator probe to verify an application-readiness signal.
In that case, I would be happy for this issue to be relabelled accordingly, or to recreate it as a feature request if preferred. 🙂