question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Configuration is cached between authorize calls

See original GitHub issue

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: https://github.com/FormidableLabs/react-native-app-auth/commit/44a47c524dd20ec47595ece6730f650d70ac6078

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

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:12 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
mklekowskicommented, Jun 27, 2019

@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.

0reactions
ThomasLargecommented, Jun 4, 2020

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Authorization Caching
Authorization caching is on by default. It may be configured from within the Administration Console through the ASI Authorization and ASI Role Mapper...
Read more >
AAA Authorization and Authentication Cache - Cisco
The AAA Authorization and Authentication Cache feature allows you to cache authorization and authentication responses for a configured set ...
Read more >
Authorization Caching | Crowd Data Center and Server 4.4
You might call this the 'has access' cache, or the 'authorization cache'. Recommended setting: Enabled. For performance reasons ...
Read more >
CallCaching - Cromwell - Read the Docs
Call Caching can be enabled in your Cromwell Configuration and the behavior can ... mean user A is authorized to read user B's...
Read more >
Enabling API caching to enhance responsiveness
When you enable caching for a stage, API Gateway caches responses from your endpoint for a specified time-to-live (TTL) period, in seconds. API...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found