Configuration is cached between authorize calls

[mklekowski]

Issue

When calling authorize method with different configuration, on the second time the configuration is taken from the first call - it is cached after first call.

The problem exist in version v4.4.0, but not in v4.3.1. I believe that the issue was introduced in this commit:
44a47c5

The mServiceConfiguration is taken instead of serviceConfiguration, which is ok for the first time or for using prefetching, and the field is not cleared when closing the chrome tab.

Steps to reproduce:

1. call authorize with issuer X
2. do not log in, just close the tab
3. call authorize with issuer Y

Result: tab is opened with issuer X
Expected result: tab is opened with issuer Y

---

Environment

• Your Identity Provider: my own
• Platform that you're experiencing the issue on: Android
• Are you using Expo?: no

[tuananhluong]

@mklekowski I think it better if there is an option to config cache or not? Do you know how to hotfix to bypass this issue? Should I revert to v4.3.1?

[mklekowski]

@tuananhluong I do not know very well the code, but as far as I understand this line (https://github.com/FormidableLabs/react-native-app-auth/blob/master/android/src/main/java/com/rnappauth/RNAppAuthModule.java#L168) should look different. It should check if the prefetched configuration didn't changed (probably the simples way is to cache configuration by the issuer or just check if the issure is different).

In my project I reverted to 4.3.1. I hope that authors of this project know how to fix it more than I, but maybe on the weekend I'll try to figure out how to fix it.

[tuananhluong]

@tuananhluong I do not know very well the code, but as far as I understand this line (https://github.com/FormidableLabs/react-native-app-auth/blob/master/android/src/main/java/com/rnappauth/RNAppAuthModule.java#L168) should look different. It should check if the prefetched configuration didn't changed (probably the simples way is to cache configuration by the issuer or just check if the issure is different).

In my project I reverted to 4.3.1. I hope that authors of this project know how to fix it more than I, but maybe on the weekend I'll try to figure out how to fix it.

I reverted to 4.3.1 too, thanks you.

[mrcluc]

Hi, i have the same problem but i use the same issuer in requests. The idea is pass by propertie additionalParameters the email for the user login in the SSO plataform.

Steps to reproduce:

call authorize with email X
the user insert your email and the authorize return to app ( OK )
call authorize with another email
the webview close returning authorize with cokkies of user of email X

Exist one method to clean the cokkies resulting of authorize. I use the version v4.3.1

[idhindsight]

Exist one method to clean the cokkies resulting of authorize. I use the version v4.3.1

Are you asking if such a method exists or stating that such a method exists? Because many are having this same problem; if you know of a good method for removing the session cookies to permit multi-user login, it would be very beneficial.

[kadikraman]

Hi @mklekowski - thanks for reporting the issue. To be clear - are you using the prefetching functionality, or is it happening just when calling authorize with two different IDPs?

[mklekowski]

Just when calling authorize with different config.

[imaginasean]

Having similar issues with iOS when authorizing against Microsoft AD. Cookies being stored and even after app deletion and re-install credentials are cached in the WebView. Currently only solution is to use display_prompt on additional parameters and require user to manually remove themselves.

[Nick-Lucas]

Same here. We have the ability to switch backend environments in our app, but this bug makes it impossible to sign-in again under a new issuer without an app restart

[aeirola]

I noticed the same thing when using multiple authentication providers.

The issue seems to happen in the following scenarios when switching between providers:

• On Android when authenticating using a configuration which doesn't include the serviceConfiguration property
• On Android when calling prefetchConfiguration before authorization, regardless of the authorization configuration

The issues doesn't happen:

• On Android when only calling authorize with the serviceConfiguration field included.
• On iOS under any circumstances.

I've made an example here https://github.com/aeirola/react-native-app-auth/tree/multiple-providers-example/Example

[aeirola]

With the example it was actually quite easy to fix the issue, so I made a PR at #470

[ThomasLarge]

This is still an issue on the current version:

For me, the fix is in the config that is passed to any of the functions, if you use issuer and use more than one OAuth client it caches the details and effects all calls (Auth, Refresh) but if you map out all of the serviceConfiguration and remove issuer you don't get this issue.