login fails with unhelpful swagger error when /users/current is unavailable (credentials are valid)

[Vad1mo]

Summary

harbor login validates credentials exclusively by calling GET /api/v2.0/users/current (via client.User.GetCurrentUserInfo in cmd/harbor/root/login.go). If that single endpoint is unavailable — even though the credentials are valid and the rest of the Harbor API is working — login fails with a cryptic go-swagger error that gives the user no useful signal.

Repro

Against a Harbor instance where /api/v2.0/users/current happens to return 502 (the other endpoints work fine, basic auth with an OIDC CLI secret is accepted):

$ harbor login <server> -u <user> -p <cli-secret>
Error: login failed: response status code does not match any response statuses defined for this endpoint in the swagger spec (status 502): {}

Direct curl against the same server with the same credentials:

Endpoint	Status
GET /api/v2.0/systeminfo	200 — auth_mode: oidc_auth, primary_auth_mode: true
GET /api/v2.0/projects (basic auth)	200 — credentials are valid
GET /api/v2.0/users/current (basic auth)	502
GET /api/v2.0/users/current (wrong password)	502
GET /api/v2.0/users, /users/search	502

The 502 on /users/* is a server-side defect on that specific instance, but it exposes two problems in the CLI:

Problems

1. Fragile validation surface. harbor login depends on a single, non-essential endpoint to decide whether credentials work. A user who can successfully harbor project list, harbor repo list, push/pull via Docker, etc. still cannot log in — because this one endpoint happens to be broken. /users/current is not needed for the login flow itself; it is used only as a "ping with auth" probe.

2. Unhelpful error message. The user sees the raw go-client/swagger string:

   response status code does not match any response statuses defined for this endpoint in the swagger spec (status 502): {}
   

   There is no indication that:

   • the HTTP status was 502 (server error, not auth error),
   • the error came from /users/current specifically,
   • the credentials themselves may still be valid.
     A user naturally concludes "my password is wrong" and keeps retrying — the actual cause is not discoverable without reading the CLI source.

Suggested fixes

Any of these would address the issue; (1) and (3) are the most impactful:

1. Use a more reliable probe for login validation — e.g. GET /api/v2.0/ping (unauthenticated reachability) combined with an authenticated call that does not require the /users subtree to be healthy. GET /api/v2.0/projects?page_size=1 would prove the credentials are accepted without depending on /users/current. Better: try multiple endpoints and accept success on any one of them.

2. Distinguish transport/server errors from auth errors. If the HTTP status is 5xx, surface it as "server error (HTTP 5xx) contacting " rather than a generic "login failed". A 401/403 means the credentials are wrong; a 502/503 means the server is sick — these deserve different messages and different exit codes.

3. Improve utils.ParseHarborErrorMsg to extract and display the HTTP status code and the endpoint that was called, instead of passing the raw go-swagger "does not match any response statuses defined in the swagger spec" text through to the user.

4. (Optional) add a --skip-verify flag to store the credentials without the pre-flight check, so a user who knows the server has a partial outage can still configure the CLI.

Environment

• harbor-cli: main @ da44eac (built locally from source)
• Harbor server: auth_mode=oidc_auth, primary_auth_mode=true
• OS: macOS (darwin/arm64)

[adityashekhawat1999]

Hi, I’d like to work on improving the error message for login failures as suggested.

[qcserestipy]

That is an interesting error scenario. Maybe we could make the login command check against /api/v2.0/users/current as it does currently and only check other points such as /api/v2.0/projects and / or /api/v2.0/ping if the api error is 5xx. If the error for /api/v2.0/users/current is 4xx we can reject with invalid credentials error message. I aggree that an addtional flag for just configuring without actually probing the login makes sense.

[qcserestipy]

I have created a PR that tries to solve this issue. How to exactly reproduce the partially broken setup? Or would it be possible that you (@Vad1mo) test it with the PR branch?

[Vad1mo]

@qcserestipy I was using OIDC ind combination with the cli-secret. I know that cli-secret is not meant for the user to loging, so I guess the cli falls for it too.

[Vad1mo]

Just checked in harbor:

/users/current is not in the OIDC CLI allowlist, so login will
always fail for OIDC users even with a correct CLI secret.

The fix belongs in harbor-cli. Use an endpoint that's actually in the allowlist (e.g.GET
/systeminfo)

[qcserestipy]

When an OIDC user hits the /users/current endpoint we most likely return status 412 as precondition failed, right? We have to handle this error return properly, same as for robot accounts. /systeminfo could be a problem if it is a public endpoint such as on the demo.goharbor.io instance using it as the primary auth check would mean wrong credentials pass validation silently.

The PR now uses a two-phase approach: /users/current remains the primary check (it reliably returns 401/403 for bad creds). If it returns a non-auth error like 412 (robot accounts, OIDC users), we fall back to /projects + /ping to verify credentials and server reachability. This way bad creds are always caught, and valid OIDC/robot logins aren't blocked by /users/current not being in the allowlist.