[lib] Disable keyserver session recovery when paramOverride is specified
Summary:
We currently use paramOverride in three places in the codebase:
- UsernameSelection on native, where we call useLegacyAshoatKeyserverCall with paramOverride set to override urlPrefix for exactSearch.
- ConnectEthereum on native, where we call useLegacyAshoatKeyserverCall with paramOverride set to override urlPrefix for both exactSearch and getSIWENonce.
- useIsKeyserverURLValid, where we call useKeyserverCall with paramOverride set to override keyserverInfos as follows. (D10290 does something similar for useVerifyInviteLink.)
keyserverInfos: { [keyserverURL]: { urlPrefix: keyserverURL, }, },
In all of these cases, we're calling a keyserver before we've authenticated to it. Since keyserver session recovery functionality is only relevant when a session invalidation occurs, it's not needed in these cases.
The reason I want to disable it broadly for cases of paramOverride being set is that paramOverride can be set to override something more important, such as the cookie. We keep just a single set of waitingCalls for each keyserver... as such, you could imagine somebody setting paramOverride to an incorrect cookie, and triggering a session recovery when the cookie in Redux is actually correct.
Depends on D10950
Test Plan:
- Test successful session invalidation in single keyserver world
- I prevented the Socket from rendering by adding a return null line before the other returns in KeyserverConnectionHandler. This avoided the Socket triggering session recovery.
- I started the iOS simulator and logged in using a test user.
- I opened the Redux Dev Tools
- I deleted the test user's cookie from the MariaDB database: DELETE FROM cookies WHERE user = 6390578 AND platform = 'ios'
- I sent a message as the test user
- I confirmed that session recovery was triggered in the Redux dev tools (and through some console logs)
- I repeated the process above several times to make sure it consistently worked multiple times in a single run
- I confirmed that the message was delivered "transparently" (without any visible issues, or evidence of session invalidation)
- Test failed session invalidation in single keyserver world
- I ran through the above test, but I hacked legacy-recover-keyserver-session.js to use the wrong password so the session recovery would fail
- I confirmed that I was logged out, and that an alert appeared explaining that my session was invalidated
- Test logging out during session recovery
- I triggered an infinite loop of session recoveries by running through the above test, but swallowing the SET_NEW_SESSION
- I logged out of the app
- I confirmed that the session recovery loop stopped, and that I was logged out successfully
Reviewers: tomek, inka
Reviewed By: tomek, inka
Differential Revision: https://phab.comm.dev/D10951