fix: use configured auth scheme prefix in API key usage examples

[argon2r]

Description

The Usage Examples panel on the API Key details page generated cURL, Node.js, Python, and Go snippets that hardcoded Authorization: Bearer <key>, ignoring the auth scheme actually configured by the API product's AuthPolicy. When a product uses a custom credentials prefix (e.g. APIKEY), consumers copied the snippet, sent Bearer ..., and received a silent 401 Unauthorized which looks like a credential/config problem rather than a display bug.

This PR reads the real prefix from the APIKey status (status.authScheme.credentials.authorizationHeader.prefix) and threads it through the snippet generator, falling back to Bearer when the field is absent (so OIDC/JWT products and older controllers are unaffected). No additional API calls are required the value is already present on the APIKey status subresource.

Fixes #547

Type of change

• [fix] Bug fix
• [feat] New feature
• [refactor] Refactor (no functional changes)
• [test] Test updates
• [chore] Dependency / config update

Changes made

• src/utils/resources.ts added authScheme.credentials.authorizationHeader.prefix to the APIKey status type.
• src/utils/generateAuthCodeSnippets.ts added an authPrefix = 'Bearer' parameter, build the credential string once (handling empty-prefix schemes to
  avoid a stray leading space), and applied it across all four snippets. Also corrected the Python snippet, which used an f"..." string with no
  interpolation.
• src/components/apikey/UsageExamples.tsx derive the prefix from the APIKey status (?? 'Bearer') and pass it to generateAuthCodeSnippets.

Test plan

• yarn lint passes (no changes after running)
• yarn build passes
• yarn i18n passes (no new user-facing strings snippet bodies are raw code, not translated)
• Tested manually in OpenShift Console
• Tested in both light and dark themes
• Tested in all-namespaces and single namespace mode

Screenshots

Before	After
Authorization: Bearer YOUR_API_KEY	Authorization: APIKEY YOUR_API_KEY

Checklist

• All user-facing strings use t() and are added to locales/en/plugin__kuadrant-console-plugin.json (no new strings introduced)
• CSS classes are prefixed with kuadrant- no bare .pf-* or .co-* selectors, no hex colors (no CSS changes)
• No console.log statements left in
• Commits include Signed-off-by line (git commit -s)

[coderabbitai]

Warning

Review limit reached

@argon2r, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 57 minutes and 22 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b7155396-612d-438c-b24c-4969e1a4fae7

📥 Commits

Reviewing files that changed from the base of the PR and between 76100e0 and 6136337.

📒 Files selected for processing (3)

• src/components/apikey/UsageExamples.tsx
• src/utils/generateAuthCodeSnippets.ts
• src/utils/resources.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[emmaaroche]

PR handles authorizationHeader.prefix correctly (screenshot shows "APIKEY" working), but doesn't handle customHeader credential type.

When I checked my cluster, APIKeys use customHeader.name: "X-API-Key" instead of authorizationHeader. With current code, those keys will still show Authorization: Bearer YOUR_API_KEY instead of X-API-Key: YOUR_API_KEY.

Three files need changes:

1. src/utils/resources.ts - Add customHeader.name field to the authScheme.credentials type definition

2. src/components/apikey/UsageExamples.tsx - Check which credential type exists: if customHeader.name exists use that as the header name, otherwise use "Authorization" with the prefix from authorizationHeader.prefix

3. src/utils/generateAuthCodeSnippets.ts - Add a headerName parameter (defaulting to "Authorization") and use it in all four snippets instead of hardcoding "Authorization". For custom headers, just use the key value; for Authorization header, use prefix + space + key.

Backstage plugin has this pattern in plugins/kuadrant/src/utils/codeSnippets.ts - see how it checks credential type and calls different snippet generators.