🐛 fix(auth): avoid race when storing fingerprint sessions#122
Merged
Conversation
…king FingerprintStore.Block and Unblock retrieve the user record via GetByFingerprint to find the user's uid, but then sent UserStoreMessages.Update with `uid: fp.uid`, which is the fingerprint id — so the wrong record (or no record) was being updated. Pass the user's uid instead.
The WS authentication middleware previously did
system.send(SessionStore, StoreSession({ uid, actorSystem }));
next(undefined);
— a fire-and-forget that returned the HTTP 101 to the client before the
SessionStore's clientIndex had been updated with the new actorSystem ↔
uid mapping. The browser would then immediately ask actors that resolve
the caller's role via determineRole → SessionStore.GetSessionForClient,
which would miss in clientIndex and return "Unknown client session".
This produced a ~30 second Dashboard reload spinner: the frontend's
afterStart asks (UserAdminActor.GetAll, FingerprintStore.GetMostRecent,
LocalUserActor.GetOwn) would hit timeouts (5s each + 5s sweep) before
the system Promise could resolve and the spinner could clear.
Converting send → ask makes the handshake wait until clientIndex is
populated, so the very first ask the new client sends resolves its
session correctly.
…n-oJOKj Fix user uid handling and WS handshake in backend
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
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
2 participants
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 reload, the backend auth middleware restores the user session and stores the session actor mapping. Previously, the middleware could continue before the actor-system session update had fully completed. Under unlucky timing, the frontend could then continue with an incomplete or stale backend session state.
This change makes the relevant actor-system calls awaitable so that the backend only proceeds after the session/user-store update has completed.
The changes make the relevant actor calls awaitable so that the backend only proceeds after the user-store update has completed.
Problem
Regular users could run into inconsistent state after reloading the UI. The likely sequence was:
This could make the UI behave as if the user/session state was not fully restored yet.
Changes
In
authMiddleware.ts:ActorSystem.ask(...)call when storing a new session/user mapping.In
FingerprintStore.ts:uid) inUserStoreinstead of the fingerprint id (fp.uid) when blocking/unblocking a user.UserStoreMessages.Update(...)send call so the update completes before returning.This should reduce inconsistent authentication/session state caused by asynchronous actor updates completing after the middleware has already continued.