fix(proxy): preserve URL path prefix during registry auth discovery

[mco69]

While Harbor itself does not support being deployed with a path prefix (e.g., /path/v2), it does support proxying registries that use them. This is significant; not only do registries like Artifactory utilizing such deployment structures, but in enterprise environments, where it is often impractical to create a distinct FQDN for every registry endpoint (and proxy may be used).

However when a registry endpoint includes a path prefix (e.g. https:///path), the authorizer's initialize method was hardcoded to probe scheme://host/v2/ for auth challenge discovery, discarding the path entirely. On the flip side, when injecting a Bearer token everything seems to work fine!

This caused two failures for path-prefixed registries:

1. Auth discovery hit the wrong endpoint (missing path prefix)
2. isTarget() refused to attach credentials to actual API requests because the stored /v2/ path didn't match the request's /path/v2/

Extract the path prefix before /v2/ from the first outgoing request and include it when constructing the auth probe URL. The isTarget comparison already handles this correctly once the stored URL contains the full prefix.

As seen in the NGINX logs below, Harbor correctly targets the custom path prefix but fails the subsequent authentication challenge:

10.42.0.39 - - [12/Mar/2026:00:21:32 +0000] "HEAD /hardcoded-path/v2/2.1.0/xwz-tbr-bom/manifests/2.1.0-20094027 HTTP/1.1" 401 0 "-" "harbor-registry-client" "-"

As seen in the NGINX logs below, Harbor correctly targets the custom path an image pull succeeds if NGING injects bearer token:

10.42.0.39 - - [12/Mar/2026:22:41:15 +0000] "HEAD /hardcoded-path/v2/2.1.0/xwz-tbr-bom/manifests/2.1.0-20094027 HTTP/1.1" 200 0 "-" "harbor-registry-client" "-"
<truncated>

Thank you for contributing to Harbor!

Comprehensive Summary of your change

Issue being fixed

Fixes #(issue)

Please indicate you've done the following:

• Well Written Title and Summary of the PR
• Label the PR as needed. "release-note/ignore-for-release, release-note/new-feature, release-note/update, release-note/enhancement, release-note/community, release-note/breaking-change, release-note/docs, release-note/infra, release-note/deprecation"
• Accepted the DCO. Commits without the DCO will delay acceptance.
• Made sure tests are passing and test coverage is added if needed.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed in website repository.

[mco69]

looks like an alternative to this is #22891

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.04%. Comparing base (6d822c2) to head (fe24105).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #22989      +/-   ##
==========================================
+ Coverage   66.02%   66.04%   +0.01%     
==========================================
  Files        1073     1073              
  Lines      116503   116507       +4     
  Branches     2939     2939              
==========================================
+ Hits        76922    76947      +25     
+ Misses      35328    35311      -17     
+ Partials     4253     4249       -4     

Flag	Coverage Δ
unittests	66.04% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/pkg/registry/auth/authorizer.go	66.27% <100.00%> (+21.15%)	⬆️

... and 10 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MinerYang]

Hi @mco69 ,

Thanks for connecting with us.

I believe for this feature we need a design approved first, and you could add a proposal on here https://github.com/goharbor/community/tree/main/proposals and join our bi-weekly meeting for further discussion if needs.
https://goharbor.io/community/

[mco69]

Hi @mco69 ,

Thanks for connecting with us.

I believe for this feature we need a design approved first, and you could add a proposal on here https://github.com/goharbor/community/tree/main/proposals and join our bi-weekly meeting for further discussion if needs. https://goharbor.io/community/

@MinerYang thanks, here is the proposal: goharbor/community#278

[reasonerjt]

Thanks @mco69, but as we discussed offline, this approach is preferred:
#22891

Let's keep this open unless we agree #22891 doesn't solve your problem.

[reasonerjt]

Thanks @mco69, but as we discussed offline, this approach is preferred: #22891

Let's keep this open unless we agree #22891 doesn't solve your problem.

Ignore this one, after more discussion, we will try to merge this one.

[wy65701436]

lgtm