fix(homepage): use service-to-service auth for catalog entity lookup

[christoph-jerolimov]

Summary

• RHDHBUGS-3339: Group-based default widget visibility failed when RBAC prevented the user from reading their own catalog entity
• Uses AuthService.getOwnServiceCredentials() for the getEntityByRef call so the backend always resolves the user entity, regardless of the caller's catalog permissions
• Permission checks (authorizeConditional) still use the original user credentials to correctly evaluate RBAC policies

Test plan

• Configure default widgets with group-based visibility (if.groups)
• Enable RBAC and remove catalog read access for a test user
• Verify the user can see group-targeted widgets on the homepage
• Verify permission-based widget visibility still works correctly

Fixes: RHDHBUGS-3339

🤖 Generated with Claude Code

[rhdh-gh-app]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@red-hat-developer-hub/backstage-plugin-homepage-backend	workspaces/homepage/plugins/homepage-backend	patch	v0.5.0

[rhdh-qodo-merge]

PR Summary by Qodo

Fix catalog lookup authentication for homepage widget visibility

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Resolve user group membership with backend service credentials despite catalog RBAC restrictions.
• Preserve caller credentials for permission-based widget visibility decisions.

Diagram

sequenceDiagram
  actor User
  participant Router
  participant Widgets as Default Widgets
  participant Auth as Auth Service
  participant Catalog
  participant Permissions
  participant Filter as Visibility Filter
  User->>Router: Request widgets
  Router->>Widgets: Pass user credentials
  Widgets->>Auth: Request service credentials
  Auth-->>Widgets: Return service credentials
  Widgets->>Catalog: Resolve user entity
  Catalog-->>Widgets: Return group relations
  Widgets->>Permissions: Authorize as user
  Permissions-->>Widgets: Return decisions
  Widgets->>Filter: Evaluate visibility
  Filter-->>Router: Return visible widgets

Loading

High-Level Assessment

The credential split is the appropriate approach: catalog identity resolution is an internal backend operation that must survive caller catalog restrictions, while authorization must remain bound to the caller. Reusing either credential type for both operations would respectively preserve the bug or bypass user-specific RBAC evaluation.

Files changed (3) +31 / -12

Bug fix (3) +31 / -12

buildUserContext.tsSeparate catalog lookup and permission credentials +15/-6

Separate catalog lookup and permission credentials

• Obtains service credentials for the user entity catalog lookup so group membership remains available when the caller lacks catalog read access. Permission authorization continues using the original user credentials.

workspaces/homepage/plugins/homepage-backend/src/defaultWidgets/buildUserContext.ts

router.tsClarify forwarding of user credentials +4/-2

Clarify forwarding of user credentials

• Renames the request credentials variable and service argument to identify them explicitly as user credentials.

workspaces/homepage/plugins/homepage-backend/src/router.ts

DefaultWidgetsService.tsInject authentication service into widget context building +12/-4

Inject authentication service into widget context building

• Adds the core authentication service dependency and passes it into user-context construction. Updates the service contract to distinguish caller credentials from backend service credentials.

workspaces/homepage/plugins/homepage-backend/src/services/DefaultWidgetsService.ts

[codecov]

❌ 1 Tests Failed:

Tests completed	Failed	Passed	Skipped
137	1	136	1

View the top 1 failed test(s) by shortest run time

createRouter returns the visible default widgets

Stack Traces | 0.036s run time

Error: expect(jest.fn()).toHaveBeenCalledWith(...expected)

- Expected
+ Received

  Object {
-   "credentials": ObjectContaining {
-     "principal": ObjectContaining {
+   "userCredentials": Object {
+     "$$type": "@backstage/BackstageCredentials",
+     "principal": Object {
        "type": "user",
+       "userEntityRef": "user:default/mock",
      },
+     "version": "v1",
    },
  },

Number of calls: 1
    at Object.toHaveBeenCalledWith (.../homepage-backend/src/router.test.ts:69:46)
    at processTicksAndRejections (node:internal/process/task_queues:103:5)

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Router test expects old argument 🐞 Bug ⚙ Maintainability

Description

The route now calls getDefaultWidgets with userCredentials, while its unit test still asserts a
credentials property. The request succeeds, but the stale toHaveBeenCalledWith assertion fails
the router test suite.

Code

workspaces/homepage/plugins/homepage-backend/src/router.ts[35]

+    const result = await defaultWidgets.getDefaultWidgets({ userCredentials });

Relevance

●●● Strong

The renamed production argument makes the existing Jest assertion stale; updating the test is a
deterministic required fix.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed route passes { userCredentials }, whereas the existing test executes that endpoint and
requires the mock to have been called with { credentials: ... }; Jest object matching does not
treat these property names as equivalent.

workspaces/homepage/plugins/homepage-backend/src/router.ts[31-35]
workspaces/homepage/plugins/homepage-backend/src/router.test.ts[56-73]

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 default-widgets route renamed the service argument from `credentials` to `userCredentials`, but the router unit test still expects the old property, causing the test to fail.

## Issue Context
Keep the assertion aligned with the `DefaultWidgetsService.getDefaultWidgets` contract while continuing to verify that authenticated user credentials are forwarded.

## Fix Focus Areas
- workspaces/homepage/plugins/homepage-backend/src/router.ts[31-35]
- workspaces/homepage/plugins/homepage-backend/src/router.test.ts[69-73]

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

---

Context sources

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Compliance rules (platform): 11 rules

✅ Cross-repo context — repo relationships

  Explored: repo: redhat-developer/rhdh (sha: 1f6ef14c)

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[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