firebase-admin-go
firebase-admin-go copied to clipboard
firebase
FR: Have GetUser return ExportedUserRecord
[REQUIRED] Step 2: Describe your environment
- Operating System version: MacOS
- Firebase SDK version: 4.6
- Library version: 4.6
- Firebase Product: auth
[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
The only way to retrieve password information for a user is to run client.Users() and iterate through every user in the system. I am trying to get the password details for a single user, but GetUser doesn't return an ExportedUserRecord
This is by design. Why do you want the GetUser() to return password information? There's no typical use case that would require that.
It requires significant workarounds to have the Firebase UID match the UID in our internal systems because it is auto-creating users. When a new user signs in, we grab all their user/provider information, delete that user and then import it again with all the same details except with a new UID. If there is a better way to do that, I'd love to hear.
@bojeil-google WDYT? Seems like a selective export use case.
@derekperkins would it be possible to maintain the mapping between Firebase UIDs and your internal UIDs in Firestore instead?
It's possible, but not something we want to do. That requires a lookup on every single auth operation vs just setting it correctly on signup.
Getting password details is protected by its own iam permission, so IMO that should govern whether or not the password is returned. I'm not sure if it is the Firebase API itself that only returns the password details on a list call or the Go SDK making a decision on whether to expose some api response fields.
All our Admin SDKs distinguish between UserRecord and ExportedUserRecord types. And currently only the "list" operation is meant to return ExportedUserRecord.
Does the api itself return the password data on other calls?
I'll also reiterate - my real issue is how to supply the UID to Firebase, so making the UID updateable would fix everything. This is just trying to make the workaround less terrible. Do you know if the List call returns newest users first? At least that would mean that I'm not iterating through 100% of our users on every new signup, likely just the first handful.
