Description

Fixes a TypeError: Cannot create property 'user' on string ... that crashes _recoverAndRefresh when storage holds a non-JSON value, and stops the raw access token from leaking into error logs as part of that exception message.

What changed?

getItemAsync now returns null when JSON.parse throws, instead of returning the raw string.

• packages/core/auth-js/src/lib/helpers.ts: change the catch branch to return null and add a comment explaining the invariant that storage in this code path is always JSON encoded by setItemAsync.
• packages/core/auth-js/test/helpers.test.ts: add a getItemAsync describe block with five cases covering missing value, empty string, valid JSON object, unparseable JSON (the corrupted chunked cookie scenario), and JSON encoded primitive.

Why was this change needed?

Reported in supabase/ssr#169 with full root-cause analysis from the reporter.

When a session is large enough to span 3+ cookie chunks (sb-...auth-token.0/.1/.2/...) and a server side refresh writes only some of the new chunks (e.g. response committed before all Set-Cookie headers go out, or partial set/remove during SSR), the browser ends up with a mix of chunks from different generations. @supabase/ssr joins them in combineChunks with no integrity check, and the combined payload either fails to base64url decode or decodes to bytes that fail JSON.parse.

Before this change, getItemAsync caught that JSON.parse error and returned the raw string. _recoverAndRefresh (GoTrueClient.ts:4544-4582) then entered the else if (currentSession && !currentSession.user) branch and tried currentSession.user = userNotAvailableProxy() on a string primitive, throwing the TypeError. The _isValidSession guard at line 4587 runs after the crash site, so it never gets a chance to clear the bad data. As a side effect, the TypeError message embeds the raw session JSON (with access_token), which means the token ends up in framework error logs and any error reporting service the app sends to.

The bug is also self reinforcing: if the corrupted string is later persisted via setItemAsync, it gets double JSON encoded (the raw string wrapped in extra quotes), and the user stays broken until they manually clear cookies.

Storage in this code path is always written as JSON. storage.setItem is only called from setItemAsync in this package (confirmed by grep), and setItemAsync always runs JSON.stringify. So a parse failure unambiguously means the entry is corrupted, and treating it as absent is the only correct interpretation. Returning null:

• prevents the TypeError (currentSession becomes null, _isValidSession rejects cleanly).
• prevents the self reinforcing double encoding (no string ever flows through _recoverAndRefresh to _saveSession).
• prevents the token leakage (no exception is built, so no token in the error message).

Refs supabase/ssr#169. A companion defense in depth fix in @supabase/ssr validates chunked cookie integrity before the value reaches this code path; that change is going up in a separate PR.

Breaking changes

• This PR contains no breaking changes

The only behavior change is that getItemAsync now returns null instead of a non-JSON string when JSON.parse fails. Callers in this package treat the result as Session | null or { user: User | null } | null and never expected a raw string in that path. The PKCE code verifier read at GoTrueClient.ts:1850 already coerces storageItem ?? '' and .split('/') an empty string ends up triggering AuthPKCECodeVerifierMissingError cleanly, which is the desired behavior for a corrupted verifier anyway.

Checklist

• I have read the Contributing Guidelines
• My PR title follows the conventional commit format: <type>(<scope>): <description>
• I have run npx nx format to ensure consistent code formatting
• I have added tests for new functionality (if applicable)
• I have updated documentation (if applicable)

Additional notes

This is the primary fix for the user visible crash on supabase/ssr#169. A separate PR on supabase/ssr adds defense in depth so corrupted chunks never reach auth-js in the first place; that one also covers a related symptom seen in production (Invalid Base64-URL character "." at position N when mixed chunks happen to contain a raw JWT separator).