Fixes for browserCookiePersistence

[jamesdaniels]

1. need to have a refresh token of off the stsTokenManager, otherwise JS SDK doesn't try to refresh and logs out
2. SameSite needs to be lax, so logout happens on navigation not just hard load
3. Safari doesn't trust localhost, so we need to set the cookie as insecure. Cookie auth already requires secure context, so we can assume http === dev on localhost
4. Don't wait for the DELETE method to complete for logout to fulfill, this is entirely optional to wipe out the refreshToken—fire and forget—the logout sentinel value "" is sufficient is the client cannot reach the backend
5. Fix dynamic setPersistence race conditions by properly swapping storage event listeners and recovering existing cookie sessions.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8d30d27

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[gemini-code-assist]

Code Review

This pull request refactors token management and persistence handling, specifically for cookie persistence. It removes hardcoded cookie-specific redaction logic from PersistenceUserManager and centralizes the handling of 'REDACTED' refresh tokens within StsTokenManager. Additionally, it updates setPersistence to properly swap event listeners and recover existing sessions. The review feedback correctly identifies a potential race condition in setPersistence where this.boundEventHandler() is called without being awaited, and suggests awaiting the resulting promise to ensure state consistency.

[gemini-code-assist]

Issue: Floating Promise & Potential Race Condition

this.boundEventHandler binds to auth._onStorageEvent, which is an async function returning a Promise<void>. Calling it without await creates a floating promise, meaning setPersistence can resolve before the authentication state is fully updated on the auth instance. This can lead to race conditions in client applications where subsequent operations are executed before the state transition completes.

Recommendation

Await the promise returned by this.boundEventHandler(). Since boundEventHandler is typed as returning void, you can cast it to unknown and then Promise<void> to satisfy the TypeScript compiler.

Additionally, note that _onStorageEvent internally calls getCurrentUser() again. If you want to optimize performance by avoiding double asynchronous storage reads, you could consider refactoring the test setup to allow calling this.boundEventHandler() directly without the pre-check, as _onStorageEvent already handles the null-user case gracefully.

Suggested change

	} else {
	const userInNewPersistence = await this.getCurrentUser();
	if (userInNewPersistence) {
	this.boundEventHandler();
	}
	}
	} else {
	const userInNewPersistence = await this.getCurrentUser();
	if (userInNewPersistence) {
	await (this.boundEventHandler() as unknown as Promise<void>);
	}
	}