-
Notifications
You must be signed in to change notification settings - Fork 1.5k
fix(security): harden Android notification receivers, token storage, and deep-link login #7447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Changes from 6 commits
eefff9f
8c9c908
718e9b9
7f78313
ccadcd0
f46aea1
169246d
0781686
bdf531a
36d748b
109a79c
473d490
9f209ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's going to happen if the user updates the app and opens the app from push notification?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On the post-update launch, restore (triggered by APP.INIT) runs migrateTokenKeysToServerScoped first, before it reads ${TOKEN_KEY}-${server}. The migration is flag-guarded A push-notification open goes through the same server-selection path, and selectServer.ts also calls migrateTokenKeysToServerScoped before its server-scoped token read — so The one exception is an ambiguous userId (shared by multiple servers): that legacy token is dropped, so those sessions re-authenticate — the user would hit login instead of |
Uh oh!
There was an error while loading. Please reload this page.