* MOB-1276: first pass
* Move realm clearing below other resets
Before we were seeing a crash where a user signsOut and while deleting realm still has a reference to a realm object somewhere the app crashes (something along the lines of "accessing object which has been invalidated or deleted", I think). Which meant that subsequent lines here after reaml.deleteAll were never hit. So, we got rid of realm but still had the signals that the user is logged in like jwt and mmkv stuff. This is problematic because UI and server request have different definitions of a user is logged in: 1) sensitive item named "username" exists, and 2) realm entry for current user exists.
I don't see how this change here get's rid of the actual crash, but at least we maybe have more likelihood of deleting all things we want to delete here.
According to @FLGMwt s investigations into this this closes MOB-820 https://linear.app/inaturalist/issue/MOB-820/user-account-seem-to-be-mixed-up#comment-80cd5378
* Do not clear auth cache and sensitive info on automatic login again initiation
I think we should fully rely on the login again action to refresh jwtToken, jwtGeneratedAt, and accessToken.
We don't know which one of them is corrupt at this point, and a re-login will give us correct new ones.
* Remove comments
A) I don't think it means that *for any reason* we delete the local database. Only when we had a 401 we were deleting everything.
B) is alleviated
* Quick fix idea
If we are on the login screen for the login again flow do not show a close button. This means the user has to close the app and open again. If the 401 persists the only action the user can take is to do the login again.
* Alternative fix: sign out on login again flow close
Adding back the X button to the login flow. Pressing it explains that this is a sign out action and signs the user out making sure we also clear realm during an entire sign out deletion flow.
* Remove test
* Update src/components/LoginSignUp/LoginForm.tsx
Co-authored-by: Ryan Stelly <ryan@inaturalist.org>
* Clean up previous code suggestion
* Revert "Clean up previous code suggestion"
This reverts commit 345bb31510.
* Revert "Update src/components/LoginSignUp/LoginForm.tsx"
This reverts commit 968fcd8601.
---------
Co-authored-by: sepeterson <10458078+sepeterson@users.noreply.github.com>
Co-authored-by: Ryan Stelly <ryan@inaturalist.org>
* extract non-react log helpers out of custom hook
* git mv useLogs to more appropriate name / location
* update logmgmt imports, clean up getLogs
* git mv Log.js Log.tsx
* remove sharing functionality from log preview screen
* reorganize debug screen w/ headers
* refactor all Debug sections for consistency
* add rolling log config, switch existing logmgmt to 'legacy' var
* factor path out of share/email for legacy wrappers
* add 'legacy' log category in prep for showing new logs
* add legacy flag to log preview screen params
* add useLogPreview for Log screen supporting legacy and aggregated recent rolling logs
* actually support sharing the new logs w/ a tmp file of concatenated recent logs
* delete low value developer screen test
* fix double reverse and handle bad filename
* Reapply "Update react-native-sensitive-info to 5.6.2 (#3346)"
This reverts commit 4bd596074c.
* Explicitly set keychainService to "app" for all calls to RNSInfo
So, apparently the default string used to save sensitive items changed from "app" to "default" between versions 6.0.0-alpha.9 and 5.6.2.
So if we install an app update built with 5.6.2 on top of our previous version (using 6.0.0-alpha.9) we can no longer find our previously stored secrets.
I am leaving the key as overridable by actual options propped in, in case someone wants to build a separate slice at one point. In contrast to accessControl which probably should not be a decision in engineerings court.
* Add comment
* Update test helpers
* Update react-native-sensitive-info
* Delete react-native-sensitive-info+6.0.0-alpha.9.patch
* Migrate sensitive info error handling
* Lint rules changes
* Add comment
* Remove incomplete type
* Add hasItem mock
* Update type
* Remove exported function getUsername
This is nowhere imported, used only in AuthenticationService. Have added the only function that makes use of getSensitiveItem( "username" ) = isCurrentUser to the Auth integration test instead.
* Update package-lock.json
* Update Podfile.lock
* Replace string with exported error code
* Add try catch to hasItem call
