[Fortune-Ndlovu]

This PR adds a CI step that verifies the frontend-injected config (<script type="backstage.io/config">) exposes at least one auth provider after RHDH starts.

Jira: https://redhat.atlassian.net/browse/RHDHBUGS-4049

[rhdh-qodo-merge]

PR Summary by Qodo

Validate guest authentication in Compose CI

🧪 Tests 🕐 10-20 Minutes

---

AI Description

• Check guest authentication after the homepage becomes available in Compose CI.
• Fail the run when the refresh endpoint errors or returns no Backstage identity token.

Diagram

graph TD
  CI["Compose CI"] --> Start["Start RHDH"] --> Home["Homepage check"] --> Auth["Guest refresh API"] --> Token{"Token present?"}
  Token -->|Yes| Pass["Continue tests"]
  Token -->|No| Fail["Fail run"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Rely on the loaded-plugins validation

• ➕ Its existing script already requests and checks a guest identity token.
• ➖ It runs later and can exit without checking authentication when no plugins are selected for validation.
• ➖ An auth failure would be reported within an unrelated plugin check.

Recommendation: Keep the dedicated early check: it makes guest authentication a direct CI requirement and gives failures a clear location. This verifies the backend guest endpoint, not the sign-in page UI itself.

Files changed (1) +7 / -0

Tests (1) +7 / -0

action.yamlAdd a guest-auth smoke check after homepage readiness +7/-0

Add a guest-auth smoke check after homepage readiness

• Adds a composite-action step that requests the guest refresh endpoint and requires a non-null Backstage identity token. The step follows the existing homepage check and respects SKIP_TEST, so applicable Compose runs fail before later validations if guest authentication is unavailable.

.github/actions/rhdh-local-compose-test/action.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🔗 Cross-repo conflicts (1)

---

View low (1)

🟡 **Low**

1. Guest auth check may reject RHDH 🔗 Cross-repo conflict

Description

The new curl request sends Accept but omits X-Requested-With: XMLHttpRequest when calling the
RHDH guest refresh endpoint. RHDH’s test client sends that header and its unit test identifies it as
required, so the check may fail against a working provider.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The guest refresh request omits the header identified as required by RHDH's test client.
## Fix Focus Areas
- .github/actions/rhdh-local-compose-test/action.yaml[301-301]
- tests/validate-loaded-plugins.sh[145-148]
## Recommended Fix
Add `-H "X-Requested-With: XMLHttpRequest"` to the new curl request. Check the existing guest-refresh request in the plugin validation script for the same compatibility requirement.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

---

---

Resolved findings

1. Sign-in failures pass the check ✓ Resolved

Description

The new CI step treats a token from /api/auth/guest/refresh as proof that the RHDH sign-in page
offers a provider, but that endpoint checks only the backend guest provider, not the frontend
signInPage selection. If the frontend omits or fails to render the guest option, the step can
remain green—even when the page says “No authentication providers are configured”—while the later
loaded-plugins check also obtains and uses a token from the same endpoint.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A backend guest token does not establish that RHDH displays a usable sign-in provider, and the existing loaded-plugins validation already obtains a guest token.

## Fix Focus Areas
- .github/actions/rhdh-local-compose-test/action.yaml[296-301]
- .github/actions/rhdh-local-compose-test/action.yaml[310-312]
- configs/app-config/app-config.yaml[1-7]
- tests/validate-loaded-plugins.sh[148-156]

## Recommended Fix
Add a browser-level check that loads the sign-in page, verifies the guest option is presented, and completes sign-in; alternatively, validate the effective frontend provider selection alongside the backend token. Configure `signInPage` explicitly for guest if that is the intended provider, and keep the new endpoint check only if it provides coverage distinct from the existing loaded-plugins validation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

---

[rhdh-qodo-merge]

Important

The /generate_labels command by Qodo was deprecated on the 1st of October 2026 and is no longer available. We recommend switching to the latest Qodo review capabilities. Learn more

[Fortune-Ndlovu]

/agentic_review

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud