Repository navigation
Conversation
PR Summary by QodoFix guest sign-in for RHDH 2.x local setup
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
Code Review by QodoResolved findings 1.
|
|
Important The |
81cd377 to
2035fe7
Compare
|
/agentic_review |
|
/cc |
rm3l
left a comment
rm3l
left a comment
There was a problem hiding this comment.
Also, I'm wondering why our current CI here didn't catch this issue at all.. Would it be possible to have a test to avoid a future regression on this?
(but not a blocker for this PR, we can look into this in a followup issue..)
|
/cherrypick dev |
|
@rm3l: once the present PR merges, I will cherry-pick it on top of DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
2035fe7 to
e101822
Compare
|
Agreed this would be good to have. Happy to follow up with a test that verifies the sign-in page loads without errors after |
e101822 to
7ee72f9
Compare
rm3l
left a comment
rm3l
left a comment
There was a problem hiding this comment.
Looks good. I think it is also a good opportunity here to replace this guest reference with ref://backstage-plugin-auth-backend-module-guest-provider, as the guest provider is available in the DPDY.
RHDH 2+ no longer bundles auth provider plugins statically, which means the guest auth provider is now loaded as a dynamic plugin at startup. This caused two problems that prevented the sign-in page from working out of the box: 1. The wait-for-plugins-and-start.sh script was only checking for the dynamic plugins config YAML to exist before starting the backend, but it was not waiting for all plugin packages to finish extracting. This meant the guest auth backend module could arrive after the auth system had already initialized, resulting in the provider never being registered. 2. The frontend app-auth plugin discovers available sign-in providers from the config keys under auth.providers, but those keys have backend-only visibility in the config schema. The frontend could not see them, so it displayed 'No authentication providers are configured' even when the backend had the guest provider fully working. This commit fixes both issues: - The startup script now also waits for the installer lock file to be removed, ensuring all dynamic plugin directories are fully extracted before RHDH starts. - A new signInPage: guest directive (with frontend visibility) is added to app-config.yaml so the app-auth plugin knows to render the guest sign-in button. - The GitHub authentication guide is updated to include signInPage: github in its example config, so users who switch to GitHub auth will also get the correct sign-in page. Resolves: RHDHBUGS-3962 Signed-off-by: Fortune Ndlovu <fndlovu@redhat.com>
7ee72f9 to
975ef6e
Compare
|
Good call, updated. The guest provider reference now uses |
|
|
@rm3l: new pull request created: #359 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What this PR does
Fix guest auth in RHDH Local 2.1 by waiting for dynamic plugin install before backend startup and explicitly setting sign-in page to guest so the frontend shows it because the backend could start before the plugin was ready and the frontend can't see backend-only auth config. So without those two changes, there'd be no guest sign-in option.
How to test
git checkout release-2.1 podman compose down -v podman compose up # Open http://localhost:7007 — should show the homepage with "Good morning, Guest!"Related issues