fix(auth): stop silent reconnect after logout without data wipe#418
Merged
Conversation
A logout without "clear local data" left the XEP-0484 FAST token in localStorage. On Tauri, LoginScreen reloads the webview after disconnect (WRY event-delivery workaround), which resets useSessionPersistence's once-per-startup guard, so the post-reload auto-connect path re-authenticated with the surviving token — silently reconnecting the user we just logged out. Clear the token synchronously in the no-clean logout path, before the reload can occur, via a new clearAutoReconnectCredentials helper.
disconnect({ invalidateFastToken: true }) deleted the client-side FAST token
only after awaiting the best-effort, network-bound server invalidation. On
Tauri the post-logout webview reload can tear down the JS context before that
await settles, leaving a usable token behind that re-enabled auto-reconnect.
Capture the token and delete the local copy in the synchronous phase (same
tick the UI goes 'disconnected'), then thread the captured token through to
invalidateFastTokenOnServer so the server-side round-trip can still
authenticate to invalidate it. invalidateFastTokenOnServer now accepts an
optional pre-fetched token and only skips the localStorage lookup when given.
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.
Summary
On the desktop (Tauri) app, choosing Déconnexion without ticking Effacer les données locales reconnected the user immediately.
Root cause: the XEP-0484 FAST token survived the logout. After disconnect,
LoginScreenreloads the webview (WRY event-delivery workaround), which resetsuseSessionPersistence's once-per-startup auto-reconnect guard — so the post-reload auto-connect path re-authenticated with the surviving token. The clean ("clear data") path was unaffected becauseclearLocalDataalready drops the token synchronously.Two layers of fix for the same cause:
clearAutoReconnectCredentialshelper). The keychain credentials were already being deleted there; only the FAST token was missed.disconnect({ invalidateFastToken: true })deleted the local token only after awaiting the best-effort, network-bound server invalidation, which the reload could outrace. It now captures the token and deletes the local copy in the synchronous phase, then threads the captured token through toinvalidateFastTokenOnServer(new optionaltokenparam) so the server-side invalidation still works.Behavior of the "clear local data" path is unchanged.