-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Users unexpectedly logged out when opening the app after some time #9869
Comments
Hi @sergiocampama, thanks for reporting this! This definitely seems weird, as #9622 was intended to fix the issue described in the article you linked, where keychain access fails due to protected data not yet being available in To help with debugging, what are the iOS versions of the users you have that are experiencing this? |
I was finally able to reproduce this in iOS 15.5, following those same steps:
This does seem related to prewarming, which can also be random and dependent on the usage patterns of the app, so not sure if it'll reproduce as easily in other phones. |
Hi @sergiocampama, two follow-up questions to help with debugging:
|
Hi @rosalyntan
|
Thanks for the response @sergiocampama! Just want to confirm one more thing -- is your For context, I believe the prewarming issues in #8695 were caused by the undocumented behavior of |
Yes, |
Seeing the same issue here – we saw this issue very infrequently before Firebase 9.0.0. Since updating to 9.0.0 a few days ago, we've had multiple testers reporting the sign out issue. Seems like something is broke here. I am running 15.4.1 and just hit the issue myself. |
Thanks @rosalyntan! Any idea on which version this might land in? |
No problem -- it should be included in |
Hello @sergiocampama, we faced a lot of logout issues with v9.0. Our app wakes up with significant locations even if the phone is locked, the keychain being probably inaccessible at this moment, making |
we just updated to 9.2.0 and I can't reproduce the log out issue any more. we haven't released this new version, but given that it was easy to reproduce before, I'm more confident that it now works as expected |
[REQUIRED] Step 1: Describe your environment
CocoaPods
iOS
[REQUIRED] Step 2: Describe the problem
We've been getting user reports that after updating to an app version that included 9.0.0, they've been getting logged out after closing the app and waiting some time, resulting in a degraded experience.
Steps to reproduce:
Sadly this is one of those issues that can't be reliably reproduced. We believe it's related to the Keychain and prewarming mitigation fix put in place in #9622, specifically to the part that checks whether
[UIApplication isProtectedDataAvailable]
returns true. There have been reports ofisProtectedDataAvailable
not returning true afterapplication(_:didFinishLaunchingWithOptions:)
, such as https://sourcediving.com/solving-mysterious-logout-issues-on-ios-15-8b818c089466. (this also contains some reproduction instructions, like force closing the app, putting the phone to sleep, waiting 30 minutes, unlock the phone and open the app)Reading the code change in #9622, if
isProtectedDataAvailable
is false, then it will wait for theUIApplicationProtectedDataDidBecomeAvailable
notification, which might never arrive ifisProtectedDataAvailable
never changed totrue
. This would result in the Auth component not being up to date on user launch, which would result in our app deciding it is logged out.Workaround
To work around this issue, we should be able to manually send the
UIApplicationProtectedDataDidBecomeAvailable
inapplication(_:didFinishLaunchingWithOptions:)
at some point after initializing the Auth component, but it might be tricky to figure out the right place if Auth is abstracted into other app-specific components.Should there be an option to deactivate this automatic mitigation/checks in light of
isProtectedDataAvailable
not working as expected in all cases? I'll leave that up to the Firebase team, but as it stands, 9.0.0 introduces a new authentication issue for us that wasn't there before (at least in our case), and for now, we'll just stay in 8.15.0 which does not contain this change.The text was updated successfully, but these errors were encountered: