fix(api): support apikey query param with custom base URL

[s0up4200]

The auth middleware used exact path matching for the /cross-seed/apply endpoint, which failed when a custom base URL was configured (e.g., /qui/api/cross-seed/apply instead of /api/cross-seed/apply).

Changed to use HasSuffix/Contains for path matching to work with any base URL configuration.

Summary by CodeRabbit

• Bug Fixes

  • Enhanced API key authentication to support custom base URLs.

• Tests

  • Added test coverage for API key authentication across various custom base URL configurations, including query parameter and header-based authentication scenarios.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The authentication middleware's path-matching logic for API key query parameter extraction was broadened to support custom base URLs, changing from exact path prefixes to pattern matching using contains/hasSuffix operations. A corresponding test was added to validate authentication across multiple custom base URL scenarios.

Changes

Cohort / File(s)	Change Summary
Authentication middleware path matching internal/api/middleware/auth.go, internal/api/middleware/auth_test.go	Modified conditional logic to use contains/hasSuffix for path matching instead of exact startsWith/equals, enabling API key query parameter extraction from custom base URLs. Added TestIsAuthenticated_APIKeyQueryParam_CustomBaseURL test covering default, custom (/qui/, /foo/bar/) paths with query param and header authentication scenarios.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10–15 minutes

• Verify the path matching logic correctly handles both standard and custom base URL scenarios
• Confirm test subtests comprehensively cover edge cases (valid/invalid keys, missing auth, protected vs. unprotected endpoints)
• Ensure the condition change from exact matching to contains/hasSuffix doesn't inadvertently match unintended paths

Poem

🐰 A path through the base, now wider and clear,
Custom URLs welcome, no need to fear,
API keys hopping through query and header alike,
Authentication middleware fixed just right! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: broadening path matching logic to support API key query parameters with custom base URLs.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/apikey-query-param-base-url

---

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

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

internal/api/middleware/auth.go (1)

26-28: Path matching change looks correct and scoped; consider future-proofing via shared constants

The new strings.Contains(path, "/cross-seed/webhook/") || strings.HasSuffix(path, "/cross-seed/apply") check correctly fixes the custom base URL issue while still limiting query-based API key extraction to the intended cross‑seed endpoints. The header‑first lookup also preserves existing behavior for clients that use X-API-Key.

If you anticipate more cross‑seed endpoints or reuse of these paths elsewhere, consider pulling "/cross-seed/webhook/" and "/cross-seed/apply" into shared constants to avoid drift between middleware and tests, but that’s optional given current scope.

internal/api/middleware/auth_test.go (1)

108-124: Optionally build URLs via url.Values for robustness against future key formats

Right now the URL for test requests is constructed via string concatenation:

url := tt.path
if tt.apiKeyQuery != "" {
    url += "?apikey=" + tt.apiKeyQuery
}

If API keys ever include characters that need URL‑encoding, this could become brittle. Consider using url.Values (or req.URL.Query() + Encode()) to set the apikey parameter instead. It keeps the test resilient to format changes with minimal extra code.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2bcd6a3 and 1a60dc4.

📒 Files selected for processing (2)

• internal/api/middleware/auth.go (1 hunks)
• internal/api/middleware/auth_test.go (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

internal/api/middleware/auth_test.go (1)

internal/api/middleware/auth.go (1)

• IsAuthenticated (19-59)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Run tests

🔇 Additional comments (1)

internal/api/middleware/auth_test.go (1)

20-106: Good, focused coverage of custom base URL and API key behaviors

The test setup and table cases do a solid job of pinning down the intended semantics:

• Valid keys via apikey query param across default and multiple custom base URLs.
• Valid key via X-API-Key header.
• Differentiation between 401 (invalid key) and 403 (no auth / non‑whitelisted endpoint).
• Guard that non‑webhook endpoints do not start accepting apikey query params by accident.

This gives strong regression protection around the new path-matching logic.