Cannot get signIn() working with Supabase
Closed this issue · 20 comments
- Explain the steps we need to take to reproduce the issue.
Hi! Trying to call .signIn()
. I'm using Expo & react-native. I get the DEVELOPER_ERROR issue. I have carefully followed all the docs from Supabase and from this repo, including reviewing all of the FAQ/troubleshooting/common causes of the DEVELOPER_ERROR. The code is simple:
GoogleSignin.configure({
webClientId: '...'
})
await GoogleSignin.hasPlayServices()
const userInfo = await GoogleSignin.signIn() // < fails here
I can get this to work in a development build only using the OAuth web flow -- by creating a web type key in Google Cloud, then copying the client key and secret into Supabase, and providing that web client ID into the .configure()
method. However, this does not work in a production build -- I get the DEVELOPER_ERROR.
Alternatively I've tried creating an Android-type key in GC (this is what Supabase docs tell you to do) with a SHA-1. So create an Android key in GC, give it a SHA-1, copy its client ID, and pass that into .configure()
. However, none of these keys/SHA-1s work either in development or production. I've tried SHA-1s from the following sources:
./gradlew signingReport
and taking the ":app:signingReport" SHA-1 key. It's the same for me for debug & release.eas credentials
and taking "SHA-1 Fingerprint" in the development, preview, or production options (again all 3 are the same SHA-1 key, although different from the key above from gradle)keytool -list -v -keystore ~/.android/debug.keystore
and taking the "SHA1 certificate fingerprint", again different from the other two- Going to the Google Play developer console > App Signing > SHA-1 certificate fingerprint, again it's different
What am I doing wrong in my config here? Totally stuck. I'm further confused by the fact that the docs for this module say that you can only pass a "web client", not "Android" type GC key to the "webClientId" arg of .configure()
(that part makes sense) -- but... the only way in GC that you can set a SHA-1 is on an Android-type GC key. So how am I supposed to be setting up a SHA-1 if I'm using a web client auth key in GC, not Android? Where am I linking an Android key, with a SHA-1, to my react-native-google-signin config, if I never pass in its client ID?
Right now in GC I have the web key set up and 4 different Android keys representing the 4 SHA-1s above, I've entered all that into Supabase, and yet I still can't get the sign in working by passing in any of the 5 corresponding client IDs as the webClientId
arg of configure()
-- except the web client key, in development builds only.
Given that the call fails before I even interact with Supabase I'm assuming it's upstream from that, but again this confuses me since the docs for this module, when discussing Firebase, mention that the DEVELOPER_ERROR is usually an issue with the Firebase config (presumably it would be similar with Supabase).
Thanks so much in advance for any assistance and apologies if anything is not clear or done according to convention, happy to do whatever additional work is needed to receive guidance.
Expected Behavior
signIn()
method should succeed and return a token to log in with Supabase.
Actual Behavior
signIn()
method returns DEVELOPER_ERROR
Environment
- react-native version: 0.74.2
- @react-native-google-signin/google-signin version: 12.2.1
- Gradle version 8.6. Not sure how to get Android version after a lot of Googling... Android studio says version 17.0.7 (Hedgehog).
We had the same kind of problem.
In our case, we came to realize that our webClienId was wrong. We had initially set client_id of oauth_client from google-services.json.
However it seems, it was supposed to be the client_id of "other_platform_oauth_client" present in the google-servieces.json
We had the same kind of problem. In our case, we came to realize that our webClienId was wrong. We had initially set client_id of oauth_client from google-services.json.
However it seems, it was supposed to be the client_id of "other_platform_oauth_client" present in the google-servieces.json
Hey there, thanks for the response! Unfortunately I'm not using Firebase, so I don't believe I have a google-services.json file at all. I'm using Supabase, which I believe doesn't require this. If I'm mistaken please let me know. Thanks again.
Me too I have same error
No updates yet folks, sorry... I have not been able to get it working.
Getting the same error using the same stack. It's hard to gauge if it's for the same reason but in my case it only happens on Android devices on either my prod or dev builds. On iOS it works on both so I'm assuming I'm using the correct (web client) ID. The strange thing is it used to work on Android. I have a feeling something might have changed that caused the Android OAuth client's configuration to be invalid but that's a complete assumption.
Likewise, I am encountering the same error on a development client build on Android. It works, maybe, 10% of the time.
Yep. I had the same error on dev client builds, and the same code was also crashing my ios simulator build completely when I press the sign in button :(
Really not sure what cleared it up but for Android I think it had something to do with removing the:
scopes: ["https://www.googleapis.com/auth/drive.readonly"],
line I had copy & pasted from Supabase's tutorial so it just added for the default scopes maybe?
For iOS I'd just not added infoPlist.CFBundleURLSchemes as mentioned in Expo's docs
Also see:
@asindhu I had more or less similar issue, and don't even work on development. Here is what I did: compile the project with "production" keys in development, and make sure that actually work on development. On PRODUCTION now any keys are senseless, as google play sign the binary and another SHA is provided (note: I am not sure if that is optional as google play asked me about this once I registered the app, so, search the SHA provided by google play console and use this). Anything else I strongly recommend to follow the Thor video on youtube for details.
Thanks everyone for chiming in. I have an update which is not likely to be all that helpful -- all of a sudden, it has started working for me. I did not change a single thing. Basically I just set this aside for a couple of weeks, came back to it, and it's working. I wonder if there was just some hours-long propagation time for some piece of the puzzle here and all that was needed was to let it settle in the correct configuration? Given how unclear all the instructions are, perhaps we're all tweaking and fiddling with it and never getting a chance to see if it works in any given configuration. Anyway here is my final setup, just for reference. Again nothing has changed since the start:
- In Google Cloud I have one web client configured. I take the client ID from this, and I pass this as the
webClientId
argument in.configure
- Also in Google Cloud, I have four Android keys configured. I don't know which of these are the right ones, but I'm not touching them now. I detailed those in my original post. So basically I take each of those different SHA-1s from each of those sources and create an Android type key in Google Cloud
- On the Supabase side, in the Google config options, I leave Client ID and Client Secret blank. In Authorized Client IDs, I paste all 5 client IDs from the 5 clients I made in Google Cloud -- so that's the web client, and the four Android clients. I enable "Skip nonce checks"
That's it. It didn't work for hours and hours of me playing around with it, I let it sit for a couple weeks, now it works. Anyway hope this helps some other folks. Unfortunate that neither Supabase nor rn-google-signin don't have these instructions plainly spelled out anywhere...
@asindhu I thought this had gone away but now it's back again for me. Exact same (expo dev client) build on an Android emulator runs fine, but on a real device is now giving DEVELOPER_ERROR again 😭 ...so I'd carry on checking your app if it's in production anywhere!
@vonkanehoffen Ugh thanks for the heads up, I will check that and make sure there's a Sentry log there or something. Good luck with it and let us know if you uncover anymore info as to the cause.
it works for me I followed this video here when you build you need to add this line strings.xml
''''''''''''''''
YOUR_SERVER_CLIENT_ID
''''''''''
maintainer edit: I doubt this has any effect.
I just did this today, had some issues with Android until now when I (think) I figured it out.
I'm using Expo / EAS / Sponsor version (but I think it should be pretty much the same in the non-paid)
- Run
eas credentials
-> SelectAndroid
- Select your
build profile
- You will now see some information, take the
SHA1 Fingerprint
-string and add it to yourClient ID for Android
credential underSHA-1 certificate fingerprint
in the gooogle cloud console. - Fill in the other information such as
Package name
and save the android credential in Google cloud. - Select
credentials.json: Upload/Download ...
andDownload credentials from EAS...
I assume this is needed when running your dev-server, not sure. - You can now exit out from
eas credentials
- It doesn't seem like you have to use your Android ClientID
**apps.googleusercontent.com
for anything. It just need to be created in google cloud console and have a validSHA1 Fingerprint
- Use your
Web application Client ID
in your app inwebClientId
in your code and also in Supabase Google provider in the fieldClient ID (for OAuth)
. - Build a dev-client using the
build profile
you selected and used in steps2
and3
- Install your build on your simulator or physical device.
This worked for me, and then you do the same process for each type of build.
Try to add your SHA-1 to app.json
{
"expo": {
"android": {
"config": {
"googleSignIn": {
"certificateHash": "<Your SHA-1 certificate fingerprint>"
}
}
}
}
}
Try to add your SHA-1 to
app.json
{ "expo": { "android": { "config": { "googleSignIn": { "certificateHash": "<Your SHA-1 certificate fingerprint>" } } } } }
Can confirm this works. In my case I got the sha1 using this command: keytool -list -v -keystore ./android/app/debug.keystore -alias androiddebugkey -storepass android -keypass android
I'll also mention I started getting this on local builds doing expo run:android
and it was only after I started configuring android app links. Not sure if it's a coincidence.
Like the docs say, the DEVELOPER_ERROR message is always a configuration error. In my case it was the SHA1 in my Android client in Google Cloud being incorrect. I had to reset my app signing key and forgot to change this value.
I recommend retracing all the steps @fedorish pointed out, it's a good overview of anything you might have missed.
Yep for me 🤞 it was the Play Store SHA1 for the android client too. Not seen any errors since.
For anyone stumbling into this issue and you do not have an expo app and you are facing this issue with an app you submitted to the play store.
I had everything setup correctly (web client id + non debug signing key for production), but the missing change was registering an OAuth 2.0 Client ID credential in GCP with the signing key sha1 from the google play console.
Once you register the sha1 make sure to add the generated client id to the list of authorized client ids in the supabase google provider configuration.
Hello and thanks for reporting,
I have pushed (yet another) update of the docs that should clarify the setup and also troubleshooting. If you feel the docs are not good enough, feel free to suggest changes to them here: https://github.com/react-native-google-signin/docs
To give an answer on the issue:
Right now in GC I have the web key set up and 4 different Android keys representing the 4 SHA-1s above, I've entered all that into Supabase
With DEVELOPER_ERROR, the error happens before supabase gets into play. You need to add these values to google cloud console first.
Where am I linking an Android key, with a SHA-1, to my react-native-google-signin config, if I never pass in its client ID?
You're not. The app is identified by its package name and hash of the certificate fingerprint.
Hope this clarifies it. I'm going to close this because the OP got it working and the docs are now better.
Thank you 🙂