-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 [firebase_auth] UserCredential does not contain displayName
when signing in and email
when linking with Apple on iOS
#9662
Comments
Thanks for the report. Using code sample provided, I see same behavior as reported. |
I've created an issue in the Firebase iOS SDK, this doesn't seems caused by FlutterFire: firebase/firebase-ios-sdk#10306 |
The behavior is currently not supported by the Firebase iOS SDK and is being worked on: firebase/firebase-ios-sdk#10068 |
The front end part is ready on the firebase iOS SDK and the backend part should land in the coming weeks so it should be fixed soon |
I'm not sure if it's related but this seems to not request the email scope at all when using 'email' scope |
To add more context, when I add the email scope, the apple sign in modal does not seem to request that info as I don't get the 'this app wants you to share your email' and also does not give me the choice to hide my email. Then, when the registration succeeds, the account is a new one even if the email already exists in the backend - it is not merged with the old account. On google sign in that works perfectly. On the video below you can see how the flow works on my app for both apple and android - and you can see that on the apple sign in, the accounts are not merged (there's no existing data upon login) but for the google sign in, the accounts are merged (you can see the existing data) RPReplay_Final1671084136.MP4Here is the code I'm using for the two
|
any update on this? |
Still waiting on native: firebase/firebase-ios-sdk#10068 |
when will this be fixed apps are being declined because of this bug |
If you encounter this issue using the flutterfire-ui package, you should know it has been deprecated. Everything worked fine for me in the newly created packages firebase_ui_oauth and firebase_ui_oauth_apple and I can retrieve Apple display name using it. |
I have the same issue with firebase_ui_oauth_apple. |
Yes, that's right. I've missed up something in my app. There is still some issue in the backend. |
This is actually the expected behavior. If you don't request "email" or "name" apple considers you don't need them and selects the default option for you. This means if the user has as default option to hide the email, it will hide it and that is why you are getting a new account on firebase. If you request the email and choose to hide the email, you will login into the same account on firebase. In relation to the rest, I'm experiencing the same issue and Apple rejects my updates all the time cause of this problem. When will it be fixed? Also in the Flutter, when you request in the scopes, you have to specify "email" and "name", but in the native scopes is "email" and "fullName". This should be the same as in the native code and well as documented somewhere. I could not find it anywhere. Thanks for the work. Have a great day. |
I'm seeing this issue, how do I access the email or name ?? final appleProvider = AppleAuthProvider(); print (userCredential.user?.email) but it's always null. Also, I have gone into device settings and deleted my app from the AppleID login...so theoretically it should return email on first attempt. |
The issue is being resolved in the this PR. |
Is there a version we can revert to in the meantime? |
My solution in the meantime:
Note that email and name won't always be provided by Apple - only for the first time the user logs in (hence the update is done only when data is actually present). I noticed you have to restart the device or wait a while to get this information again. |
I think the same issue persists on Android, too. Did anyone notice that? |
@avidan-chen I've used your solution and it does work when it is the first time that the user logs in, as you mentioned. And my review still got rejected. Have you added any additional information for the reviewer to get your app approved? |
@kirilllapshev we got rejected because we were asking for the user's name and email (since we couldn't get it after the user logged in). Once we implemented this code, we removed the UI asking the user to input their name and email and Apple approved. |
@avidan-chen Removing this is not necessary. Based on Apple guidelines, prefilling the info for the user should be enough. What's not acceptable, is that you ask for the user name and email but, let's say, in the sign-up/login form you ask to fill in this info manually. |
@avidan-chen but do you ask for the user's name at some point? Or you just removed it from the app? Do you think by not asking for the user's name on the apple's signing modal and then renaming the name's label on the sign-up/login form inside you app from "Your name" to something else like "Name inside the app" would solve the problem? |
@kirilllapshev after first login, the app displays a profile page where the first name and last name is pre-populated. The user can change them if they wish. In the initial version, they were mandatory fields and were empty and that's why Apple rejected the app - they said we should fill it automatically for the user. |
@mkobuolys you are correct, prefilling the info for the user was enough to get the app approved. Bad choice of words on my part - we didn't remove the UI completely, just pre-filled it. |
Thank you for your solution @avidan-chen! We were being rejected because although we were updating the |
@Lyokone now that firebase/firebase-ios-sdk#10068 is merged, is this fixed? |
@felixgabler It's merged but not released yet. |
Yes, it has to be released in an iOS Firebase SDK first (you can check on the release note page), then we have to do a new release of FlutterFire Core, including the native SDK. It'll probably be released in a couple of weeks. |
Because for AuthorizationCredentialAppleID user data fields (first name, last name, email) will only be set if this is the initial authentication between the current app and Apple ID so it is my solution:
|
This problem is already fixed in iOS SDK: https://firebase.google.com/support/release-notes/ios#10.7.0 Hopefully, we will get an SDK version bump soon 🤞 |
It should be fixed with the next release. PR is in review: #10652 |
I noticed that the issue regarding missing displayName and email when signing in and linking with Apple on iOS was recently closed, but it doesn't seem to be fully resolved yet. I'm still experiencing the same issue and I'm wondering if there are any updates on this. Firebase iOS SDK version 10.7.0 has been confirmed with firebase_core: 2.9.0 and firebase_auth: 4.4.0. |
Yes, the problem still exists. |
Using Firebase 10.8.1 and problem persists |
I have same issue. Any update? |
Bug report
Describe the bug
The
signInWithProvider
returns aUserCredential
wheredisplayName
is missing in the apple.comproviderData
.Additionally, the
linkWithProvider
returns aUserCredential
where bothdisplayName
andemail
are missing in the apple.comproviderData
.This happens for new Apple IDs too (for testing with existing IDs, make sure to disconnect them from the App through the Apple ID settings).
On Android, it works correctly!
Steps to reproduce
Steps to reproduce the behavior:
Expected behavior
The
UserCredential
should return thedisplayName
(andemail
) as it does on Android.Sample project
Here is the relevant code:
Additional context
I know that Apple only returns it on the first sign in. This is however NOT the issue here because it works on Android if the Apple ID is successfully disconnected. Tested on both real devices and simulator. Also tested with a totally new Apple ID.
Flutter doctor
Run
flutter doctor
and paste the output below:Click To Expand
Flutter dependencies
Run
flutter pub deps -- --style=compact
and paste the output below:Click To Expand
The text was updated successfully, but these errors were encountered: