Open jeremym148 opened 2 years ago
bbirman
commented
2 years ago Do you see this on Mobile SDK 9.2.1? In that version we changed the default accessibility from kSecAttrAccessibleWhenUnlockedThisDeviceOnly to kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly to address a similar sounding issue (https://github.com/forcedotcom/SalesforceMobileSDK-iOS/issues/3437).
benhi
commented
2 years ago Hello @bbirman , I tried the new SDK 9.2.1, but unfortunately the problem persist.
bbirman
commented
2 years ago Thanks for the update-- do you have any other information about when/how the failing key access is being attempted? Is the app setting a certain keychain access level instead of using the default?
benhi
commented
2 years ago Hello @bbirman. I can provide you the log that was printed.
Remote Access Consumer Key is missing from Plist file
2022-02-10 15:38:00.601491+0200
AnuragTiwari1
commented
2 years ago I also faced this, in my case the device was locked and then I got a notification. when I tried to open the notification my device asked for pin and when the app opened I was on login page, I am using hybrid app (react-native-sdk) and being able to reproduce the issue consistently.
I am using v9.2.0
Edit: I will try if upgrading to v9.2.1 fixes this
az-oolloow
commented
2 years ago So I think this might be related to the comment I made here: https://github.com/forcedotcom/SalesforceMobileSDK-iOS/pull/3447#issuecomment-982654888
Not sure if notification wake could do it, but basically if the app is launched in the background and not interactively, the migration in 9.2.1 doesn't have a chance to execute.
For us the solution to the protected data woes was to implement our own logic to safeguard against it, see here: https://github.com/forcedotcom/SalesforceMobileSDK-iOS/issues/3437#issuecomment-978363811
bbirman
commented
2 years ago @az-oolloow based on the comment you made before, we changed the upgrade step to only run if the keychain + protected data was available so that once the user launched the upgraded app the log outs would stop (there could potentially be one more log out after upgrading if it was launched in the background before the user launched it). Did you still see log outs after that which made you need to keep the other logic you mentioned?
iowlit
commented
2 years ago Version of Mobile SDK Used: 10.0 Issue found in Native App or Hybrid App: Native OS Version: 15.5 Device: all Steps to reproduce: random, when the phone or the app is not used after 30 minutes Actual behaviour: the app is getting logged out in background
Hi. Our users are also experiencing sudden logout while app is in background. Remote notifications are disabled in our app. We are accusing "pre-warming" functionality but it is almost imposible to prove. We have no idea how to fix the issue at the moment.
There are logs right before the app is getting logged out:
bcriscuolo-sf
commented
2 years ago @iowlit we've recently addressed this in an app; it requires a bit of workaround to accomplish a clear path forward though.
I believe that technically your users are not logged out. Rather, MobileSDK entered a state (when the app was either pre-warmed or launched in the background) where it could not access the keychain to retrieve the authentication token. This is likely due to the device being locked, possibly after a reboot.
In our method of addressing this, we chose to interrupt our flow in application:didFinishLaunching:withOptions: if we determined that we did not have access to the keychain or protected data. The former was tested by attempting to write something to the keychain, the latter by uiApplication.isProtectedDataAvailable. If either fail, we consider the device not ready for our app.
For simplicity, we present an alert; the button action performs the balance of the setup needed (including initializing MobileSDK).
If the button was tapped, it must mean that the user has unlocked the device and both keychain and protected data area available.
Another option is to observe the protected data notifications. While these do not have a 1:1 mapping with keychain access, they are likely close enough to satisfy what MobileSDK needs.
Best of luck, Brian
iowlit
commented
2 years ago Hi @bcriscuolo-sf. Thanks for your advice. I am likely to add precondition on uiApplication.isProtectedDataAvailable at the very beginning of application:didFinishLaunching:withOptions: the app will simply crash in background with no additional user interaction required.
Zokor
commented
1 year ago We're also having this issue in the new 10.2 and it wasn't present in the 9.0.0.
Any idea when this can be fixed?
bbirman
commented
1 year ago @Zokor do you have logs you can share? do you know if it's happening when receiving a push notification?
Zokor
commented
1 year ago @bbirman we don't have logs. we don't have push notifications unfortunatly. We suspect it may be related with IOS pre-warming the app.
It looks like sdk trying to refresh token while iPad is in sleep mode, and while device is asleep sdk can't access Keychain. so when we open open an app again, it logout user because of no refresh token.
The thread urls seems interesting: https://sourcediving.com/solving-mysterious-logout-issues-on-ios-15-8b818c089466 https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app/about_the_app_launch_sequence#3894431
These are the hints we have so far to solve this.
However for logs gonna ask if it's possible to have iOS system ones from the QA team.
bcriscuolo-sf
commented
1 year ago @Zokor I believe we've experienced a similar issue, and I think it is happening because of either app warming or background launch.
What you are seeing as a logout may not really be a logout - rather, MobileSDK doesn't have the ability to access the refresh token, and so gets itself into a login state - but in the meantime, you are still logged in.
To combat this, we introduced a check in our applicationDidFinishLaunching where we check both data protection and keychain permissions and access. If we can access both (as appropriate), continue the launch process and initialize MobileSDK (successfully!).
If we cannot access either, return false from applicationDidFinishLaunching and show an alert with a retry button.
If the user ends up seeing the retry button, it means that they've not only brought the app to the foreground, but also that the device is in a usable state (data protection and keychain).
Upon tapping retry, we "complete the launch" - initializing MobileSDK, etc.
While I can't share the code, the flow is pretty easy and has worked consistently for us. Please reach out with any questions - happy to help.
Zokor
commented
1 year ago @bcriscuolo-sf thank you :) you guys added that on this 10.2.0 version? or will be added in a future release?
bcriscuolo-sf
commented
1 year ago We're consuming 10.2.0, but all that is app-side - really just controlling for the app lifecycle better and ensuring MobileSDK is referenced only when in a state for which it can succeed in initializing.
Zokor
commented
1 year ago I see, problem is. We're using Ionic & Angular. We don't have anyone with knowledge of Objective C
Please fill out the following details:
After reading some documentation in the community: https://sourcediving.com/solving-mysterious-logout-issues-on-ios-15-8b818c089466
https://developer.apple.com/documentation/uikit/app_and_environment/responding_to_the_launch_of_your_app/about_the_app_launch_sequence
We can see that during the pre-warm app of iOS, the ProtectedData is not accessible so the access token and refresh token are not accessible and the login web view is pushed on top of the app. Maybe we can avoid it using isProtectedDataAvailable or kSecAttrAccessibleWhenUnlocked before processing any API calls to be sure that the app is able to access the Keychain
All our iOS apps are impacted