fix(jmap): request /jmap/session directly to survive iOS auth-drop on redirect - #39
Open
koolninad wants to merge 1 commit into
Open
fix(jmap): request /jmap/session directly to survive iOS auth-drop on redirect#39koolninad wants to merge 1 commit into
koolninad wants to merge 1 commit into
Conversation
… redirect Signing in from the iOS build against a Stalwart server fails with "No account found in JMAP session". Stalwart's discovery endpoint /.well-known/jmap answers with a 307 to /jmap/session. iOS NSURLSession strips the Authorization header when it auto-follows that redirect, so the app gets an unauthenticated session back — HTTP 200, empty accounts — and resolveAccountId throws. Browsers keep the auth header on same-origin redirects, which is why the webmail never saw this; it only bites the native app on iOS. Request /jmap/session directly so the header stays attached, falling back to /.well-known/jmap on 404 for servers that don't expose the Stalwart path. Also treat a 200 with no accounts as an auth failure. Stalwart answers that way for missing or invalid credentials instead of sending a 401, so a user who fat-fingers their password currently gets "No account found in JMAP session" rather than "Invalid credentials". Tests updated for both behaviours; full suite passes (the pre-existing auth-store.test.ts parse failure on main is unrelated).
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
1 participant
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.
Sign-in from the iOS build against a Stalwart server fails with "No account found in JMAP session".
Cause
fetchSessionrequests/.well-known/jmap. Stalwart answers that with a 307 to/jmap/session, and iOSNSURLSessiondrops theAuthorizationheader when it auto-follows the redirect. The app therefore receives an unauthenticated session — HTTP 200 with emptyaccounts— andresolveAccountIdthrows at the end of the chain.Browsers preserve the auth header across same-origin redirects, so the webmail never sees this. It only affects the native app on iOS, which matters now that there's an iOS TestFlight pipeline.
Fix
/jmap/sessiondirectly so the header stays attached, falling back to/.well-known/jmapon a 404 for servers that don't expose the Stalwart path.Testing
vitest run src/api/__tests__/jmap-client.test.ts— 20 pass, including the two updated expectations. Full suite passes;src/stores/__tests__/auth-store.test.tsfails to parse onmainalready and is unrelated to this branch.This has been running in a downstream fork against Stalwart on both platforms since early July.
🤖 Generated with Claude Code