Prior behavior: TokenAuth middleware rejected any invalid/malformed
Bearer with 401 before dispatch — even on paths in isPublicAPIPath
(/api/v1/auth/*, /health, share links, public plan-limits). A stale
credential in ~/.pad/credentials.json (typically left over after wiping
a test DB) made every CLI invocation 401 on the very first
CheckSession() call, INCLUDING the endpoints needed to recover (login,
forgot-password). Users could only fix it by manually deleting their
credentials file.
The matching IP-change-revoked branch in the same file already had the
right pattern (middleware_auth.go:114-117): when the path is public,
fall through to the handler unauthenticated and let it decide. This
patch mirrors that across the four invalid-Bearer branches:
- Authorization header doesn't start with "Bearer "
- padsess_* token doesn't validate (stale or wiped session)
- pad_* token format wrong (length, prefix)
- pad_* token doesn't match a live API token
Extracted into a small rejectInvalidBearer helper so the policy is
visible in one place. Protected endpoints continue to 401 — the
regression guard in TestTokenAuth_ProtectedPath_StillRejectsInvalidBearer
pins that.
Pre-existing bug; not introduced by TASK-1216 / TASK-1217. The new
bootstrap flows just made it more visible because anyone testing fresh-
install scenarios is likely to wipe DBs and end up with stale creds.
Tests in middleware_auth_public_paths_test.go cover:
- /auth/session with stale padsess_* Bearer → 200 with public payload
- /auth/session with malformed Authorization → 200
- /auth/session with garbage token format → 200
- /auth/session with non-matching pad_* token → 200
- /auth/login with stale Bearer + valid creds → 200 (the actual user-
visible recovery scenario)
- Protected /workspaces with invalid Bearer → still 401 (regression)
Closes: BUG-1227.
Related: IDEA-1226 (per-server credentials — proper design fix; this is
the safety-net fix that complements it).
xarmian
ce0be1ed0a