forcedotcom / SalesforceMobileSDK-ReactNative

BSD 3-Clause "New" or "Revised" License
49 stars 54 forks source link

Logout issue on iOS with RN deferred login #281

Open Ruslan-Mz opened 2 years ago

Ruslan-Mz commented 2 years ago

Hello!

It seem's there's a bug on iOS similar to this one: https://github.com/forcedotcom/SalesforceMobileSDK-ReactNative/issues/72

Description: App created using temlpate https://github.com/forcedotcom/SalesforceMobileSDK-Templates/tree/dev/ReactNativeDeferredTemplate Using iOS 15 User's log's in and logs out normally But then when user presses "Login" he is logged in automatically without requesting credentials. This prevents multi-user setup and also is a security threat.

If the app is restarted, then credentials are asked correctly But if I try to reset ReactNative context programatically (with DevSettings.reload() in debug mode or with RNRestart.Restart()) then the issue is still there. I've briefly checked the iOS code for logout, but for now havent found any suspicious places.

Is this a known issue? Or maybe there's a workaround for this?

(investigating more, will update if found out something).

bbirman commented 2 years ago

Hi @Ruslan-Mz, I tried the template with iOS 15.0 & 15.5 but I'm not able reproduce, is there something else I should try to recreate what you're seeing?

Ruslan-Mz commented 2 years ago

Hello @bbirman! Thank you for attempt to reproduce, it gave me more information. I've tried to re-create the app and still was receiving the issue. But when I've changed to totally default login through test.salesforce.com it started to work. But when using custom community URL it's logging in immediately. On closer look, when internet was slower, I've noticed that login web-view is appearing for a second or less, so it means that user is logged in through the web-view after all.

When using default I see in logs: SFOAuthCoordinator webView:didStartProvisionalNavigation: host=test.salesforce.com : path=/services/oauth2/authorize SFOAuthCoordinator webView:didStartProvisionalNavigation: host=test.salesforce.com : path=/

But when using custom (community) URL, then after SFOAuthCoordinator webView:didStartProvisionalNavigation: host= : path=/services/oauth2/authorize I immediately see retrieval of user: SFIdentityCoordinator SFIdentityCoordinator:Starting identity request at https://test.salesforce.com/id//***

One difference I see is that test.salesforce.com doest have .well-known/auth-configuration that is requested before oauth navigation: SFSDKAuthConfigUtil getMyDomainAuthConfig:loginDomain: Advanced authentication configured. Retrieving auth configuration from https://test.salesforce.com/.well-known/auth-configuration SFSDKAuthConfigUtil Org config request failed with error: Status Code: 404

But on community we have it. Maybe some auth configuration parameters are the cause of this?

Investigating more.

Ruslan-Mz commented 2 years ago

Haven't yet found the root cause. But auth-config has nothing to do with it - checked by removing the code to fetch it. User is still logged in if I use community URL, no matter if default or custom login page is used.

Again confirming that the difference between first login after app restart or rebuild is that on first login those steps are called: SFOAuthCoordinator webView:didStartProvisionalNavigation: host= : path=/services/oauth2/authorize SFOAuthCoordinator webView:didStartProvisionalNavigation: host= : path=/login then on entering credentials SFOAuthCoordinator webView:didStartProvisionalNavigation: host=*** : path=/setup/secur/RemoteAccessAuthorizationPage.apexp SFIdentityCoordinator SFIdentityCoordinator:Starting identity request at https://test.salesforce.com/id/...

But on following login attempts identity is retrieved immediately after navigating to path=/services/oauth2/authorize For default test.salesforce.com the process stays the same on each attempt Suspecting that something may be cached. Is it server side? Does anybody have a clue what to check?

Investigating more.

Ruslan-Mz commented 2 years ago

Addition research on current topic: Together with SF developer we have found out more about this auto-login without credentials. On login event Salesforce creates 3 AuthSession objects in the database (3 types: Oauth2, ChatterNetworks, TempChatterNetworks). On logout it removes only Oauth2 type object, 2 other remains. But if we manually delete "ChatterNetworks" object from DB, then auto-login wont happen and user will be asked for credentials. ChatterNetworks object expiration time now is 2 hours, and if it's not deleted but those 2 hours pass, then user also will be asked to enter credentials. So it's not clear yet why it happens, and if ‘ChatterNetworks’ session should be deleted automatically after successful logout. On web logout it's also not deleted, but user is asked for credentials correctly, same on android. So only iOS is failing.

bbirman commented 2 years ago

thanks for all the info! I'll investigate more and update here

Ruslan-Mz commented 2 years ago

We have found a workaround, similar to the one described here - https://salesforce.stackexchange.com/questions/24556/why-salesforce-com-logs-the-user-in-automatically-after-his-her-session-has-been I've modified file SFOAuthCoordinator.m lines 346 and 646 (in methods continueNativeBrowserFlow and generateApprovalUrlString) and added "&prompt=login" to the end of generated URL strings there. Now it's requesting login each time user opens login page, as expected! This requires keeping those local changes, instead of loading SDK on build process, but works.

ruchiranavishka commented 2 years ago

Having a same kind of issue where Logging out from oauth.logout() redirect to connected app permission requested page not to logging page. This only happens on IOS.

The issue was fixed after doing the workaround as mentioned in https://github.com/forcedotcom/SalesforceMobileSDK-ReactNative/issues/281#issuecomment-1165603965

Will this be fixed in next sdk releases?

wmathurin commented 2 years ago

Thanks @Ruslan-Mz, we will look at bringing that fix into the SDK.

oktalk commented 1 year ago

Any progress on this issue? I am experiencing the same thing.