search

firebase / firebase-ios-sdk

Firebase SDK for Apple App Development
https://firebase.google.com
Apache License 2.0
5.67k stars 1.49k forks source link

Bug: Auth.auth().currentUser Returns Nil on Some Devices Despite Available User Data. #13231

Open jesus-mg-ios opened 4 months ago

jesus-mg-ios commented 4 months ago

Description

The Auth.auth().currentUser property consistently returns nil on specific devices, even though a logged-in user is expected. In contrast, the getStoredUser(forAccessGroup:) method intermittently returns a user object, suggesting that the user data is accessible. The behavior remains consistent across device lifecycles, where the method either returns a user object or does not, without variation. The whole extension works on a concurrent environment.

Also functions are working authenticated despite Auth.auth().currentUser is nil. State listener does not change the rules, I mean, it does not change Auth.auth().currentUser, and also does not return other than nil on those cases Auth.auth().currentUser is nil.

Reproducing the issue

I'm not sure, but maybe it more reproducible when updates happens. Because what I saw in some cases is:

Auth.auth().currentUser is nil and getStoredUser(forAccessGroup:) is also nil until the user enters on the app, then getStoredUser(forAccessGroup:) returns a value in the extension.

Even sometimes both Auth.auth().currentUser getStoredUser(forAccessGroup:) are nil until the extension restart.

Could be any kind of deadlock trying to get the keychain element?

Firebase SDK Version

10.25

Xcode Version

15.2

Installation Method

Swift Package Manager

Firebase Product(s)

Authentication

Targeted Platforms

iOS, macCatalyst

Relevant Log Output

No response

If using Swift Package Manager, the project's Package.resolved

Expand Package.resolved snippet
```json Replace this line with the contents of your Package.resolved. ```

If using CocoaPods, the project's Podfile.lock

Expand Podfile.lock snippet
```yml Replace this line with the contents of your Podfile.lock! ```
jesus-mg-ios commented 4 months ago

@rizafran any update on this? The bug has a high repro on end devices.

rizafran commented 4 months ago

Thanks for reporting, @jesus-mg-ios. In order to investigate and replicate the issue, could you provide the following info:

jesus-mg-ios commented 4 months ago

Several ones...

paulb777 commented 4 months ago

See this stackoverflow question and answer - https://stackoverflow.com/q/69201789/556617

jesus-mg-ios commented 4 months ago

I've already implemented a state listener @paulb777, but it didn't resolve the issue. The state listener initially triggers with a nil value, even though the data is available in the keychain, and it never triggers again with the correct user value.

paulb777 commented 3 months ago

Does 11.0.0 (released today) make any difference?

google-oss-bot commented 3 months ago

Hey @jesus-mg-ios. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

yarodevuci commented 3 months ago

I have the same issue on 11.0.0 .. each time i reset the app auth is nil! resetting entitlement did not help.

Downgrading to FirebaseCore 10.29.0 (was 11.0.0) solved the issue....

Removing FirebaseAppCheckInterop Removing FirebaseAuthInterop Removing FirebaseCoreExtension Removing FirebaseSharedSwift Removing RecaptchaInterop

not sure if those files have anything to do with it? those are removed after downgrade from 11

yarodevuci commented 3 months ago

@jesus-mg-ios have you figured it out ?

yarodevuci commented 3 months ago

@rizafran happens on any phones and simulator for me running iOS 17, can't test other OSs

Auth.auth().signIn(withEmail: email, password: xxx completion: { result, error in

Auth.auth().currentUser returns nil after app restart ..

rizafran commented 3 months ago

Hi @yarodevuci, I tried to reproduce the issue using v11.0.0 on iOS 17 simulator, but my currentUser is returning a value every time I restart the app. Is it possible for you to provide a sample app that reproduces the issue?

yarodevuci commented 3 months ago

Hi @yarodevuci, I tried to reproduce the issue using v11.0.0 on iOS 17 simulator, but my currentUser is returning a value every time I restart the app. Is it possible for you to provide a sample app that reproduces the issue?

I can draft maybe a sample app yes, do you know if between 10 and 11 version a new json config file needs to be updated?

Some people mentioned the updating their entitlements file helped too, so I am not sure if from brand new project issue does not exist, compared to older project

rizafran commented 3 months ago

@yarodevuci, may I know which json config file you're referring to?

yarodevuci commented 3 months ago

@yarodevuci, may I know which json config file you're referring to?

GoogleService-Info.plist

rizafran commented 3 months ago

Hi @yarodevuci, there's no need to update in your GoogleService-Info.plist file if you're updating to v11.0.

yarodevuci commented 2 months ago

@rizafran here is my update

I use to check in AppDelegate Auth.auth().currentUser != nil ... but now Auth.auth().currentUser is nil each time ..

I tried 

Auth.auth().addStateDidChangeListener { auth, user in
         //Auth.auth().currentUser  is not nil here anymore
}

So I can't no longer use direct Auth.auth().currentUser in AppDelegate?

minhnguyen-iosdev commented 2 months ago

I also faced this bug, Auth.auth().currentUser doesn't return logged in user in AppDelegate in Firebase 11.1.0.

In my apps, user is signed in anonymously when Auth.auth().currentUser == nil so now it's always logged in as anonymous.

    func application(_ application: UIApplication,
                     didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        FirebaseApp.configure()

        if Auth.auth().currentUser == nil {
            Auth.auth().signInAnonymously { _, error in
                if let error = error {
                    print(error)
                }
            }
        }

        return true
    }

So I decided to switch back to Firebase 10.29.0.

yarodevuci commented 2 months ago

@rizafran can you let us know if this an actual bug or updated implementation usage is now required?

rizafran commented 2 months ago

Thanks for sharing more info, @yarodevuci. I was able to reproduce the same behavior and I've raised this to the engineer for investigation.

dfmuir commented 2 months ago

+1 for this, I believe that our users are encountering an issue related to this bug in the wild.

paulb777 commented 2 months ago

I've reproduced.

It's always been true that there is a race condition initializing currentUser.

However, it looks to be much more prevalent to be slower to initialize in Firebase 11.

After anonymous login, currentUser is initialized after the configure call in Firebase 10, but not 11.

I've isolated to the keychain read - OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)returningQuery, (CFTypeRef *)&result);

In Firebase 11, the worker thread gives up control, but Firebase 10 does not.

I even converted the call to Objective-C in Firebase 11 with no change in behavior.

paulb777 commented 2 months ago

We're considering adding two alternative APIs:

  1. A published property that’s an enum:

    • unknown
    • loggedIn(User)
    • loggedOut

  2. An async API that waits for the keychain to be read before returning the current user

jesus-mg-ios commented 2 months ago

@paulb777 could be that even the user data is available, the profile data is stalled or outdated? https://github.com/firebase/firebase-ios-sdk/issues/13571

yarodevuci commented 2 months ago

@paulb777 can we expect a fix in the next version ?

paulb777 commented 2 months ago

There are two problems discussed in this issue.

We don't yet have a plan for either of these.

jesus-mg-ios commented 2 months ago

There are two problems discussed in this issue.

  • One is that the currentUser API is inconsistent at app startup. That has always been an issue that we're exploring alternative APIs in a future release.
  • The other is that the recommended workaround for the first issue is to use a listener. There is a report that the listener is not working correctly, but we have not reproduced that issue.

We don't yet have a plan for either of these.

if this is true @paulb777 , then when I request the currentUser after some time (e.g., 2 minutes after app launch), it should be updated. However, it seems that this is not always the case. For example, after changing the displayName within the same app, and restart it again, sometimes the displayName reverts to the old one and no changes are made along the app lifecycle to this property, even the reload function for the current user doesn't always work as expected, and only logging out and back in resolves it.

paulb777 commented 2 months ago

@jesus-mg-ios A repro case of a change getting reverted would be helpful

bryandubno commented 2 months ago

@paulb777 I think there's actually a change in logic (or unintended consequence) going on between 10.29.0 and 11.0.0. With the use of @synchronized in the previous 10.x codebase, the cached user is being read from disk and stored as currentUser before configure completes, which allows us to make use of the cached authenticated user.

In 11.x, configure completes without the authenticated user (even if there's one cached on disk). If developers have been creating an anonymous user based on the state of current user after configure completes, we'll improperly create another anonymous user.

Pigpocket commented 1 month ago

Any update on this? I cannot get the user from auth.currentUser or auth.getStoredUser on version 11.2.0.

bryandubno commented 1 month ago

I had to downgrade until 11.x mimics the 10.x behavior

Pigpocket commented 1 month ago

I still get nil for auth.currentUser when trying to delete anonymous users on all 10.x versions.

paulb777 commented 1 month ago

@Pigpocket Does the addStateDidChangeListener API help? https://firebase.google.com/docs/auth/ios/start#listen_for_authentication_state

raho commented 1 month ago

Using Firebase SDK 11.3.0 I observe that addStateDidChangeListener initially callbacks with user=nil immediately followed by non-nil user data. I was testing on a real device (iPad) when NOT attached to the Xcode debugger (but still a debug version installed using Xcode). When the app was started using Xcode it properly provided the non-nil user on first listener callback.

tsjamm commented 5 days ago

We've been seeing similar issues of currentUser not being available on an App I work on. After a bit of analysis, it could be due to a combination of:

  1. Using a Keychain User Access Group
  2. iOS App Pre-warming - if the auth is configured with access group in AppDelegate's didFinishLaunchingWithOptions, it might run even when device is locked, so keychain may not be accessible.
  3. The discussion above where configure call completes without currentUser being available in 11.x

I see a recent PR #14067 @paulb777 Would this handle the app pre-warming scenarios where keychain is not accessible when device is locked?

yoching commented 3 days ago

Still happening on my project and cannot upgrade to 11.x. Are there any ways to avoid this?

bryandubno commented 3 days ago

Same here. Really hoping they look at this: https://github.com/firebase/firebase-ios-sdk/issues/13231#issuecomment-2356432490

jesus-mg-ios commented 3 days ago

Please @yoching, @bryandubno, @tsjamm, @raho, @Pigpocket, @dfmuir @yarodevuci @unxavi upvote the issue description to give it more visibility.

yarodevuci commented 2 days ago

Please @yoching, @bryandubno, @tsjamm, @raho, @Pigpocket, @dfmuir @yarodevuci @unxavi upvote the issue description to give it more visibility.

Firebase team is aware of the issue, but I feel like they not gonna do a fix for this...

jesus-mg-ios commented 2 days ago

I hope they will do it, because it is a critical part of their SDK. @ncooke3, any updates on this? Do we have an ETA for a solution or any pathway to address it?

ncooke3 commented 10 hours ago

Apologies for the delay everyone, and thank you for your patience. I'll be looking into this more this week.