Hi, I already posted on Github Discussions, but just saw the announcement telling people to use this forum instead.
I was surprised when I headed over to the docs and the google OAuth guide completely changed overnight. It seems to have shifted entirely to use @react-native-google-signin/google-signin instead of expo-auth-session/providers/google. Took me a while to realize the change, it would be nice to have a ‘last updated’ in the top of the doc’s page for sanity check. Apparently there was a merged pull request 2 days ago that completely changed the docs regarding google auth in expo apps.
I just implemented Google authentication in my React Native app last week, so do I need to change everything right away? Is the old way now deprecated? I feel like the guide got more complicated tbh.
We are also having same issue. It works in test environment but not in production. We have used expo-auth-session/providers/google package. Still now getting an error “type:dismiss” in production
Can you please help as soon as ?
We are using bare workflow.
Do we need to eject the project to use this [@react-native-google-signin/google-signin] library? or is there any other way to use google sign in with Expo?
@pintubetech I have been driving myself and one of the expo team members (@amanhimself ) crazy trying to figure this out for a few weeks and @salesp07 saved me with this:
had the same issue a while ago. What solved it for me was:
Making my package name lowercase, and exactly the same on Firebase / Google Cloud and
my expo app
Making slug all lowercase
Make scheme the same as slug
Make new eas credentials after changing the slug and update Firebase/Google Cloud with
the newly generated SHA1 accordingly
Hope it helps!
Long story short google/android is SUPER fussy about the slug,scheme and package name and it doesn’t like ANY of these your going to get {type: dismiss}
Yes, we changed the guide due to some reported issues with third-party providers and yes, they are now deprecated and will be removed in a future SDK. These third-party libraries wraps native SDKs so there is less chance of that changing in future.
The complexity you’re mentioning is there for the configuration part because there are different elements associated that are not in our control. Google or any other third-party providers require some steps to follow.