Exempt /api/openapi.json and /torznab/api from auth middleware#6
Merged
Conversation
Two related bypasses for path-handler-own-auth endpoints: * /api/openapi.json — public API spec for AI/tooling discovery (same precedent as /metrics and /health, both already exempt). * /torznab/api and /api alias — the Torznab handler does its own apikey check against TORZNAB_API_KEY. Without exempting these paths, the gamarr auth middleware rejected Prowlarr requests with 401 (Prowlarr sends ?apikey=<torznab-key>, not the gamarr API_KEY) before they ever reached the Torznab handler. The /api alias is mounted on the exact path /api only, so this does NOT match /api/search, /api/library, etc. The Torznab exemption was missed in the original v1.2.0 work because the LXC 104 isolated test deployment used no AUTH_USERNAME / API_KEY, so gamarr was in 'anonymous admin' mode and the middleware passed everything through. The bug manifests only when the user configures authentication. New TestIsExempt locks in 23 positive + negative path assertions, including suffix-attack guards.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two related auth-middleware fixes for endpoints that do their own auth internally:
/api/openapi.json— public API spec for AI/tooling discovery (same precedent as/metricsand/health)./torznab/apiand/apialias — the Torznab handler does its own apikey check againstTORZNAB_API_KEY. Without exempting these paths, the gamarr auth middleware rejected Prowlarr requests with 401 (Prowlarr sends?apikey=<torznab-key>, not the gamarrAPI_KEY) before they ever reached the Torznab handler.Why this wasn't caught at v1.2.0
The LXC 104 isolated test deployment used no
AUTH_USERNAME/API_KEY, so gamarr was in "anonymous admin" mode and the middleware passed everything through. The Torznab feature works fine there but breaks the moment a user configures authentication.Test plan
TestIsExemptwith 23 path assertions (positive + negative + suffix-attack guards).go test -race -count=1 ./...clean.gofmt,vet,staticcheckclean.Backwards compatibility
Strictly additive (paths added to the exempt list, none removed). The Torznab handler's own apikey check is unchanged and still gates access when
TORZNAB_API_KEYis set.