fix(register): read home JWT from localStorage so step-2 avatar uploads

RegisterPage step 2 writes the new token to localStorage but defers
initSession (and thus the authStore.token write) until after the avatar
upload, to keep AuthRedirect from yanking the user off /register
mid-upload. The home-origin branch of setTokenForOriginResolver was
reading authStore.token, so getTokenForOrigin('') returned null during
that window — transferStore.startUpload threw "not authenticated" and
the surrounding catch-and-ignore silently dropped the avatar. Align the
resolver with the home api client and read localStorage so both paths
share one source of truth for the home JWT.
This commit is contained in:
Jannis Braun
2026-05-05 12:53:48 +02:00
parent 49e9047005
commit 702d539e23
3 changed files with 82 additions and 3 deletions
+2
View File
@@ -561,6 +561,8 @@ Called by `useAuth()` hook when token exists but user object is null:
3. `initSession(token, finalUser)` -- activates Zustand state, triggers redirect
4. Navigate to redirect param or `/channels/@me`
**Auth-token source of truth.** During the step-2 avatar upload, the JWT lives in `localStorage` only -- `authStore.token` (Zustand) is still null because step 3 hasn't fired. Both the home `api` client (`api/client.ts`) and the home-origin branch of `setTokenForOriginResolver` in `instanceStore.ts` therefore read the home JWT from `localStorage.getItem('backspace_token')`, never from `authStore.token`. This keeps `transferStore.startUpload` (and any other path that resolves a home-origin bearer) authenticated during the registration window. The two stores are written together everywhere else (`initSession`/`logout`), so the divergence only matters between steps 1 and 3 here.
---
## 8. Federation-Aware Identity Utilities