Repository navigation
Stop forwarding custom auth headers across redirects - #468
Merged
Merged
Conversation
Handlers set the configured upstream auth header on the request itself before handing it to the client. When upstream redirected to another host, Go's client copied that header to the next hop: it strips only Authorization and Cookie, so a "header" type credential such as X-JFrog-Art-Api reached the redirect target. The auth transport already applies credentials per hop, scoped to each hop's URL. - Remove Proxy.applyUpstreamAuth and Proxy.AuthForURL; auth comes only from the transport - Add a server test that redirects a header-authenticated upstream to another host and asserts the header stays with the upstream - Wire handler tests' auth through the transport, as the server does
andrew
approved these changes
Oct 14, 2026
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
2 participants
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.
Handlers set the configured upstream auth header on the outgoing request before handing it to the HTTP client. When an upstream redirects to another host, Go's client copies every header to the next hop except
Authorization,WWW-AuthenticateandCookie. Atype: headercredential (for exampleX-JFrog-Art-Api) therefore reached the redirect target.The auth transport (
internal/httpclient/transport.go) already applies credentials per hop, scoped to that hop's URL, so the handler-side copy was redundant.Changes
Proxy.applyUpstreamAuthandProxy.AuthForURL. Auth now comes only from the transport, which everyProxy.HTTPClientand the artifact fetcher go through (server.go).AuthForURLget their auth through the transport, the same way the server wires it.Bearer and basic auth were not affected, because Go strips
Authorizationon cross-host redirects.Testing
internal/server/upstream_auth_redirect_test.go: a real server withtype: headerauth scoped to upstream A, and A redirects to host B. Before the fix it failed withredirect target received X-Api-Key = "registry-secret", want none. It now passes, and A still receives the header.go test -race,go vetandgolangci-lintv2.13.1 pass.cmd/proxymirrornever used upstream auth, before or after this change. That is left for a separate change.