FR: Change behavior of onAuthStateChanged. #4133

heckad · 2020-11-30T07:19:59Z

[REQUIRED] Describe your environment

Operating System version: windows 10
Browser version: Google Chrome 88
Firebase SDK version: 8.1.1
Firebase Product: auth

Problem:
If a user was logged and try to open spa app on page wich required auth access the app should waiting until auth will be confirmed and only then call callback onAuthStateChanged with the user object. This check can be quite long (more than 5 seconds with slow 3g).

Propose:
Call callback when we find user information in storage with this user object without waiting for the end of the auth check. If auth check return that user was logout than call callback with user null.

Thanks!

The text was updated successfully, but these errors were encountered:

hsubox76 · 2020-12-01T22:24:42Z

I'm not sure I understand what the request is. Is the problem the same as the one you are asking about in the comment here: #462 (comment)? If so, does the answer there solve your problem?

Or is this a separate issue?

heckad · 2020-12-02T05:44:45Z

Yes, this is the same problem. I tried your solution, and they didn't help because if a user wants to get access to the private route, then the router will wait until verification competes and the user will see a white screen all time. If I remove check verification from the route, then route redirects the user to a login page. Because I need the auth call callback less than 100ms even they can't get information from google.

gustavopch · 2022-06-17T20:30:06Z

@hsubox76 I think I have a similar use case, although it's a multi-page application instead.

Whenever the user navigates to a new page, everything including Firebase is initialized from scratch. I have some JS code that will dynamically render the page by setting document.body.innerHTML, but it can only run after the auth state is known. The code is somewhat like this:

<header>
  <script type="module">
    onAuthStateChanged(getAuth(), user => {
      document.body.innerHTML = `Hello, ${user.displayName}!`
    })
  <script>
</header>
<body></body>

Even on a fast connection, it takes 300ms for the callback to be called, so the browser won't wait and will show the blank page (because the body is empty in the HTML itself). So this is what the user sees in the screen:

First page fully loaded
White flash (for about 300ms or longer as the auth state is obtained from the network)
Second page fully loaded

On the other hand, if onAuthStateChanged invoked the callback immediately with cached data (from IndexedDB or Local Storage), paint holding would take place and the user would see this in the screen:

First page fully loaded
Second page fully loaded

Summarizing: if onAuthStateChanged loaded immediately with cached data, there wouldn't be a white flash between navigations (when loading a new page). That would provide a much superior UX for multi-page applications. I know the initial auth state would potentially be stale/expired, but in that case the callback would be called again with fresh data. IIRC, that's just how Firestore's snapshot listeners work (edit: actually not, a new listener takes about 120ms to receive the first snapshot here; edit 2: about 40ms with persistence enabled which is still too slow for paint holding to work).

gustavopch · 2022-06-23T16:05:38Z

I found that this is where the problem happens:

firebase-js-sdk/packages/auth/src/core/user/reload.ts

Lines 31 to 75 in cdada6c

    
           export async function _reloadWithoutSaving(user: UserInternal): Promise<void> { 
        
             const auth = user.auth; 
        
             const idToken = await user.getIdToken(); 
        
             const response = await _logoutIfInvalidated( 
        
               user, 
        
               getAccountInfo(auth, { idToken }) 
        
             ); 
        
             _assert(response?.users.length, auth, AuthErrorCode.INTERNAL_ERROR); 
        
             const coreAccount = response.users[0]; 
        
             user._notifyReloadListener(coreAccount); 
        
             const newProviderData = coreAccount.providerUserInfo?.length 
        
               ? extractProviderData(coreAccount.providerUserInfo) 
        
               : []; 
        
             const providerData = mergeProviderData(user.providerData, newProviderData); 
        
             // Preserves the non-nonymous status of the stored user, even if no more 
        
             // credentials (federated or email/password) are linked to the user. If 
        
             // the user was previously anonymous, then use provider data to update. 
        
             // On the other hand, if it was not anonymous before, it should never be 
        
             // considered anonymous now. 
        
             const oldIsAnonymous = user.isAnonymous; 
        
             const newIsAnonymous = 
        
               !(user.email && coreAccount.passwordHash) && !providerData?.length; 
        
             const isAnonymous = !oldIsAnonymous ? false : newIsAnonymous; 
        
             const updates: Partial<UserInternal> = { 
        
               uid: coreAccount.localId, 
        
               displayName: coreAccount.displayName || null, 
        
               photoURL: coreAccount.photoUrl || null, 
        
               email: coreAccount.email || null, 
        
               emailVerified: coreAccount.emailVerified || false, 
        
               phoneNumber: coreAccount.phoneNumber || null, 
        
               tenantId: coreAccount.tenantId || null, 
        
               providerData, 
        
               metadata: new UserMetadata(coreAccount.createdAt, coreAccount.lastLoginAt), 
        
               isAnonymous 
        
             }; 
        
             Object.assign(user, updates); 
        
           }

Firebase indeed has the auth state stored locally (the user parameter), but it forces a network request to check if it should be invalidated (_logoutIfInvalidated()). That request is what takes a lot of time. The listeners will only be notified after it completes. TBH, I'm not even sure if there's much of a point in storing the auth state locally if it's always requested again from the server, and not used for optimistic UI.

Instead, I think it could immediately notify the listeners with the cached auth state and THEN proceed to check if the invalidation is actually needed (most times it won't be, at least for my app).

I understand that for some apps the invalidation may be important for security, but if that's the case, then at least add an option to initializeApp() where we can opt in to using the cached auth state. It can also consider how much time ago it was last checked. If there was a session in the last 24 hours, use the cached auth state, otherwise not.

Please consider following my suggestion. It's a low-hanging fruit that will make all MPAs using Firebase Auth a lot faster.

I'll even leave a draft diff here so you have something to start with 😊:

 export async function _reloadWithoutSaving(user: UserInternal): Promise<void> {
   const auth = user.auth;
+
+  // Notify listeners with the cached user before checking if the invalidation is needed
+ // so the app can initialize fast.
+  user._notifyReloadListener(user);
+
+  // Wrap in a promise that's not awaited so it doesn't block the function termination.
+  Promise.resolve(async () => {
     const idToken = await user.getIdToken();
     const response = await _logoutIfInvalidated(
       user,
       getAccountInfo(auth, { idToken })
     );

I know this diff would break other places using the _reloadWithoutSaving() method, but I hope it can at least illustrate my suggestion. In reality, you'd probably add a options: { acceptCached?: boolean } | undefined parameter and only pass { acceptCached: true } when Firebase is being initialized.

sam-gc · 2022-06-23T17:24:44Z

Hi @gustavopch, thanks for digging into this more! My main concern is that this proposal blurs the lines between onAuthStateChanged() and onIdTokenChanged() (the former only updates when the user's uid changes, the latter updates whenever the token itself updates).

With that said, there may be a way to deliver this functionality using a different/new API. I will discuss this more closely with the team.

gustavopch · 2022-06-23T18:35:02Z

@sam-gc That makes sense. I'll explain my actual use case. Pseudo-code:

let unsubscribe
onAuthStateChanged(getAuth(), authState => {
  unsubscribe?.()
  unsubscribe = onSnapshot(
    doc(getFirestore(), `users/${authState.uid}`)
    user => { console.log('User loaded') }, 
  )
})

As you can see, I can only add the Firestore listener once I know the ID of the current user, so even when I have Firestore persistence enabled, it won't load the user document as fast as it could. I'm also not sure if there's any code inside Firestore that would wait for the auth state to be known even if my own code wasn't wrapped in an onAuthStateChanged(), so that's something to keep in mind too.

gustavopch · 2022-06-24T12:59:03Z

@sam-gc Well, maybe simply populate getAuth().currentUser with the cached auth state upon initialization? That way, you don't need to mess with onAuthStateChanged(). So the code above would need to be adapted to:

let unsubscribe
const handleAuthState = authState => {
  unsubscribe?.()
  unsubscribe = onSnapshot(
    doc(getFirestore(), `users/${authState.uid}`)
    user => { console.log('User loaded') }, 
  )
}

handleAuthState(getAuth().currentUser)
onAuthStateChanged(getAuth(), handleAuthState)

Note: added unsubscribe to the snippet so people using it as a reference in the future don't forget.

sam-gc · 2022-06-24T15:23:05Z

The problem with either is that it changes the way the API operates, which is a breaking change. The team is exploring other options that avoid changing existing functionality (i.e. by adding this as a new feature).

One thing to note is that if the token is too old, the database read will fail on the server with a permission denied error. I'm not sure how this will interact with the local cache

gustavopch · 2022-06-24T15:45:35Z

One thing to note is that if the token is too old, the database read will fail on the server with a permission denied error.

@sam-gc Here's how I think it would work:

If there's cached data, no matter what, just show it as fast as possible, same as how it would work if it was offline (I think it's how Twitter works for example).
Proceed to verify the token.
- Valid? Proceed to fetch new data from Firestore.
- Invalid? Try to refresh the token.
  - Successful? Proceed to fetch new data from Firestore.
  - Failed? Notify the app so it can navigate to the sign-in screen.

Assuming most times the token can be refreshed, then most times it will work seamlessly. In cases where the token can't be refreshed, then the user may see the cached data for a moment and then be forced to re-authenticate. Of course, that's assuming the developer wants to use the cached data, but it would be optional.

cbreezier · 2023-01-12T06:18:52Z

Hi, any movement on this? @sam-gc

TBH, I'm not even sure if there's much of a point in storing the auth state locally if it's always requested again from the server, and not used for optimistic UI.

Wholly agreed here.

Right now, the predominant workaround is to store some value in local storage (eg, a boolean, or maybe even the entire auth.currentUser object) and manually check that to determine "logged-in-ness" faster than the sdk can re-resolve the current user. This is so clunky and forces us to re-implement logic and duplicate data that is already tracked by the sdk.

99.99% of the time, the user will be successfully validated, and only in 0.01% of the time might the user be deleted, or credentials revoked. We should optimise for the common case instead of the rare one.

The problem with either is that it changes the way the API operates, which is a breaking change.

I don't see how pre-populating the user with the stored data from IndexDB changes the way the API operates. The onAuthStateChanged will still correctly notify us about changes to the auth state. Even auth.currentUser doesn't break any definitions. In both cases, the APIs just work off of the most current information that they can, and correct themselves as soon as new information is available.

Edit: even today, onAuthStateChanged and auth.currentUser aren't guaranteed to serve fresh data. If a user has a browser tab open overnight and their credentials are revoked, when they view the browser in the morning they'll still be "logged in" and referencing stale data, until the sdk can re-validate everything asynchronously in the background.

pcl · 2023-06-23T13:12:10Z

I'm running into this issue as well.

TBH, I'm not even sure if there's much of a point in storing the auth state locally if it's always requested again from the server, and not used for optimistic UI.

Wholly agreed here.

In my experience, if a device is offline, then the request to refresh the user will fail fast and the app will launch quickly. So IMO it's great that the cache exists, and is certainly not just there as an optimization.

However, when on a slow network (such as a 3G connection), the refresh request has to time out before anything else can proceed, which is frustrating.

I'm currently hacking around this problem by intercepting fetch (which I already do for logging purposes) and adding a 2-second timeout to the requests to identitytoolkit.googleapis.com and securetoken.googleapis.com.

It'd be great if the initialization sequence didn't block on this refresh, or if there were some other way to fetch the current user object from local storage while the initialization progresses. I don't really want to add my own user cache on top of the one that Firebase Auth provides, since that presents a bunch of additional synchronization issues to manage.

cbreezier · 2023-06-30T01:26:55Z

I just wanted to add that other than the slow 3G connection use case, anyone in a region where Firebase Auth isn't replicated to will also feel a lot of pain.

My customers are primarily in Australia, and the 300-600ms latency makes every single page refresh really clunky feeling, because I can't render anything if I don't know if the user is logged in or not.

cbreezier · 2023-09-08T05:28:16Z

@sam-gc Hello, friendly bump - any movement or new information on this issue?

chdsbd · 2023-09-16T17:59:47Z

This is a really annoying bug in Firebase. I've been trying to dig though the firebase sdk to see how to fix this, but it's pretty esoteric

Looking in the Chrome stack trace, I think onSnapshot waits for this auth call to complete before continuing to load:

firebase-js-sdk/packages/firestore/src/remote/persistent_stream.ts

Lines 446 to 461 in 086df7c

    
           Promise.all([ 
        
             this.authCredentialsProvider.getToken(), 
        
             this.appCheckCredentialsProvider.getToken() 
        
           ]).then( 
        
             ([authToken, appCheckToken]) => { 
        
               // Stream can be stopped while waiting for authentication. 
        
               // TODO(mikelehen): We really should just use dispatchIfNotClosed 
        
               // and let this dispatch onto the queue, but that opened a spec test can 
        
               // of worms that I don't want to deal with in this PR. 
        
               if (this.closeCount === closeCount) { 
        
                 // Normally we'd have to schedule the callback on the AsyncQueue. 
        
                 // However, the following calls are safe to be called outside the 
        
                 // AsyncQueue since they don't chain asynchronous calls 
        
                 this.startStream(authToken, appCheckToken); 
        
               } 
        
             },

wahibimoh · 2023-10-13T11:00:14Z

Any update on this? this was raised on 2020 and still no progress what so ever.
All we are asking for is to give developers the option to trust the cached user, seriously, how hard can this be to implement?
Cached user is already trusted in offline mode, so just give us this option.

This is killing the whole firebase ecosystem for MPA.

parmy · 2024-10-26T12:35:25Z

There does not appear to be a fix for this issue.

I'm working with a react native app which is also web enabled.

I can confirm react-native-firebase does not have the same issue, I'm assuming the currentuser details are stored locally to allow for offline access.

Like most apps, I initally load the Sign In screen and wait for onAuthStateChanged to be triggered. If a user is logged in and refreshes the page, then even running on a fast network with no network delays, I'm finding two issues:

~30 seconds elapse before onAuthStateChanged is triggered
If the user attempts to login, before onAuthStateChanged is triggered, the login won't complete until auth completes it's initial check.

I can provide the a simple app if that is required so you can replicate the issue. The proposals above make perfect sense.

I guess the only workaround is for apps where user convenience is important, the workaround for now is:

When user logs in, if auth persistance is local, store user credentials in local storage
On page load, use the stored user credentials whilst waiting for onAuthStateChanged to be triggered
If the token has expired or the user is no longer valid, sign out the user. This is quite difficult to manage if the user is offline and not confusing invalid user with user offline.

The problem with this approach is onAuthStateChanged has to be triggered before auth will respond to sign in\out requests. Sorry firebase auth team, this all needs either a serious rethink and proper solution or in case we're all getting this wrong, a real working example.

Finally, I did try using:

import ReactNativeAsyncStorage from '@react-native-async-storage/async-storage';
import { initializeAuth } from '@react-native-firebase/auth';
import getReactNativePersistence from 'firebase/auth';

auth = initializeAuth(app, {
persistence: getReactNativePersistence(ReactNativeAsyncStorage)
});

As documented in the react-native-firebase documentation, however; there are issues with modules not existing in packages and I wasn't able to get any combination of the above working.

Looking forward to a fix from the firebase team.

Thanks.

google-oss-bot added the feature request label Nov 30, 2020

hsubox76 added question and removed question labels Nov 30, 2020

Feiyang1 added the api: auth label Nov 30, 2020

gustavopch mentioned this issue Jun 23, 2022

Don't wait resolving firebase.auth() when enablePersistence() is used #3302

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

FR: Change behavior of onAuthStateChanged. #4133

FR: Change behavior of onAuthStateChanged. #4133

heckad commented Nov 30, 2020

hsubox76 commented Dec 1, 2020

Uh oh!

heckad commented Dec 2, 2020

Uh oh!

gustavopch commented Jun 17, 2022 •

edited

Loading

Uh oh!

gustavopch commented Jun 23, 2022 •

edited

Loading

Uh oh!

sam-gc commented Jun 23, 2022

Uh oh!

gustavopch commented Jun 23, 2022 •

edited

Loading

Uh oh!

gustavopch commented Jun 24, 2022

Uh oh!

sam-gc commented Jun 24, 2022

Uh oh!

gustavopch commented Jun 24, 2022 •

edited

Loading

Uh oh!

cbreezier commented Jan 12, 2023 •

edited

Loading

Uh oh!

pcl commented Jun 23, 2023

Uh oh!

cbreezier commented Jun 30, 2023

Uh oh!

cbreezier commented Sep 8, 2023

Uh oh!

chdsbd commented Sep 16, 2023

Uh oh!

wahibimoh commented Oct 13, 2023

Uh oh!

parmy commented Oct 26, 2024 •

edited

Loading

Uh oh!

FR: Change behavior of onAuthStateChanged. #4133

FR: Change behavior of onAuthStateChanged. #4133

Comments

heckad commented Nov 30, 2020

[REQUIRED] Describe your environment

hsubox76 commented Dec 1, 2020

Uh oh!

heckad commented Dec 2, 2020

Uh oh!

gustavopch commented Jun 17, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gustavopch commented Jun 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sam-gc commented Jun 23, 2022

Uh oh!

gustavopch commented Jun 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gustavopch commented Jun 24, 2022

Uh oh!

sam-gc commented Jun 24, 2022

Uh oh!

gustavopch commented Jun 24, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cbreezier commented Jan 12, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pcl commented Jun 23, 2023

Uh oh!

cbreezier commented Jun 30, 2023

Uh oh!

cbreezier commented Sep 8, 2023

Uh oh!

chdsbd commented Sep 16, 2023

Uh oh!

wahibimoh commented Oct 13, 2023

Uh oh!

parmy commented Oct 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gustavopch commented Jun 17, 2022 •

edited

Loading

gustavopch commented Jun 23, 2022 •

edited

Loading

gustavopch commented Jun 23, 2022 •

edited

Loading

gustavopch commented Jun 24, 2022 •

edited

Loading

cbreezier commented Jan 12, 2023 •

edited

Loading

parmy commented Oct 26, 2024 •

edited

Loading