Potential liability with instructions for Google Authentication

Expo Application Services (EAS)
1

In the process of adding Google authentication for our existing app, we followed these instructions: Authentication with Google and AuthSession API - Expo Documentation

However, those steps involve creating a new key, which overrides any existing keystore. Because we didn’t have a backup of the key that we already had in EAS, this led to us not being able to upload new builds to Google - and in turn we will now have to reset our upload key.

Yes, we should’ve had a backup of the key used for uploads, but I also think that the documentation should make it more clear that you’ll actually replace any existing keys in the process. I’m also not sure if a new key is even needed for that step in the process, if you already have a keystore?

Bottom line: I think that

  1. It would be very convenient if EAS would keep copies of previous keystores so that we could revert such a change
  2. The documentation ought to be updated to reflect the fact that you don’t need to generate a new key if you already have one.
2

hi @insats - you’re absolutely correct, this docs page is misleading and I’m sorry for the trouble that this has caused you.

you raise a good point about possibly keeping a backup of the keystore around for some period of time in case a developer accidentally clears theirs. i’ll discuss this with the team.

i appreciate you bringing this up. @amanhimself is going to fix the docs page asap

2 Likes
3

@brents Hi brents, since you are speaking with the team can you ask them to update on a solution to the android standalone race issue that causes the google auth process to always return a response of “dismissed” ? I just went through the entire key reset process last week and it was a real “kick me while I’m down” to find out that on android the google authentication doesn’t even work after finally solving the upload key one.

4

do you have a github issue you can point to?

5

Hi yes

this video also mentions it at about 9:20

and this one at about 31:30 the guy runs into it, basically he has to wait about 2 mins on the screen to choose and account and then it will work but any earlier and it does not redirect and ends up on the google homepage

1 Like
6

@brents Hi again brents was that what you were looking for? I can grab other stuff on this issue if not. I have been looking in to it for a solution for a fair amount of time at this point so plenty to choose from at this point haha

1 Like
7

thanks! @amanhimself will investigate that

8

Thanks @brents and @amanhimself
Please forgive my ignorance but is there any way I can follow, the progress on this issue? be notified when you reach a conclusion?
Mostly curious if I should go look for another library for goggle sign in or if I should just sit and wait? haha

9

Hi @freem11

I haven’t tried this myself, but you could see if this works for you:

1 Like
10

@amanhimself will follow up here

11

Hi @freem11,

Apologies for the inconvenience caused by the docs not being able to convey the right steps. Working on updating the documentation.

Tested it with development and preview builds and I’m not seeing the issue response: {"type": "dismiss"} mentioned in the video you referenced. This video also uses useProxy which was deprecated with SDK 48. We recommend go through steps as mentioned the docs here: Use Google authentication - Expo Documentation.

If you are having the issue after setting up your app credentials as described in docs, feel free to reach out and open an issue in GitHub with a minimal reproducible example and I’m happy to take a look into it.

It’s tricky to reproduce the issue in this video as I could not on my end.

12

an improvement for ergonomics around creating keystores will land in the next release of eas cli: [eas-cli][ENG-8763] Select default android keystore by khamilowicz · Pull Request #1889 · expo/eas-cli · GitHub

this will make it hard for people to accidentally overwrite their keystores