Skip to content
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

Profile data from provider..? #2158

Closed
ForbiddenEra opened this issue Sep 6, 2019 · 7 comments
Closed

Profile data from provider..? #2158

ForbiddenEra opened this issue Sep 6, 2019 · 7 comments

Comments

@ForbiddenEra
Copy link

So, in my search about this I essentially read that "firebase doesn't support getting extra profile data" such as birthdate/gender/phone numbers, etc.

We can add scopes for google:

	        provider.addScope('https://www.googleapis.com/auth/user.birthday.read');
	        provider.addScope('https://www.googleapis.com/auth/user.phonenumbers.read');
	        provider.addScope('https://www.googleapis.com/auth/userinfo.email');
	        provider.addScope('https://www.googleapis.com/auth/userinfo.profile');

and for Facebook:


			provider.addScope('user_birthday');
			provider.addScope('user_age_range');
			provider.addScope('user_gender');
			provider.addScope('user_location');

Which, indeed asks the user if we can have that data. Great. Now, having to use a separate API library to take the token I get from firebase auth to make a request for this info (as part of my sign up process, especially) seems a bit much - as in why wouldn't I just use said API library to do the auth requests? I'm not sure about other use cases but what attracted me to firebase-auth was what seemed to be easy implementation of several OAuth signin providers.

When I auth from facebook, I do indeed get what I ask for:

{…}
​additionalUserInfo: {…}
​isNewUser: false
​​profile: {…}
​​​age_range: Object { min: 21 }
​​​birthday: "01/01/1969"
​​​email: "[email protected]"
​​​first_name: "Jai"
​​​gender: "male"
​​​granted_scopes: Array(6) [ "user_birthday", "user_location", "user_gender", … ]
​​​id: "scrubbed"
​​​last_name: "Era"
​​​location: Object { name: "scrubbed", id: "scubbed" }
​​​name: "Jai Era"
​​​picture: Object { data: {…} }
​​providerId: "facebook.com"

which is awesome - I can verify the user is old enough to use our site, also, getting a phone number allows me to prepopulate the rest of the sign-in form on our site with that.

Google sign-in, even though I'm asking for those, doesn't provide me this automatically..? I do see additionalUserInfo.getProfile() but am unsure how to invoke that or if that will indeed return what I need.

Google profile response:

profile: {…}
​​email: "scrubbed"
​family_name: "Era"
​given_name: "Jai"
​​​granted_scopes: "openid https://www.googleapis.com/auth/user.phonenumbers.read https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/user.birthday.read"
​​​id: "115910160273107257994"
​​​locale: "en"
​​​name: "Jai B"
​​​picture: "https://lh4.googleusercontent.com/-Jt1iysRY34Q/AAAAAAAAAAI/AAAAAAAAAAA/ACHi3reBFGD_VLwsy-BTEA7QnKh74M_ZWQ/photo.jpg"
​​​verified_email: true

Now, if firebase isn't supposed to provide this information (as it seems my searching says) then why is it for FB? If one needs no other functions for anything else on any of these providers, one can use firebase completely for user auth alone, which is (was?) my plan.

Basically all I want to do is present the user the option of signing up with email (which will also use firebase auth still), facebook & google (maybe others later).. Creating an account on our site also requires further information such as phone number, verifying the user is 18 and email, so we can use the profile returned to pre-populate these fields simply allowing the user to verify it and proceed to our next step in the sign-in process.

So:

  1. Am I missing something for Google? Is there a way to ask for this info with firebase?
    1a. If not -> why is it returned with FB when I set those scopes? Is it based on what the provider returns in a single http request upon firebase doing auth with the provider? Thus, when logging in FB freely returns that info in the oauth request while google doesn't freely provide it in the oauth login response?
    1b. If not -> Since it's returned by FB, can we have it added to the google object?

It seems intuitive that I would add scopes to request certain information and get it, if the user authorizes, upon login -> the fact that this is working already for FB is awesome, if I can get that same profile information with google I won't need anything else for doing 3rd party provider logins on my site besides firebase. Having to add a whole other API library for a single request for one provider seems like a lot of overhead?

@google-oss-bot
Copy link
Contributor

I found a few problems with this issue:

  • I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
  • This issue does not seem to follow the issue template. Make sure you provide all the required information.

@bojeil-google
Copy link
Contributor

Firebase Auth is focused on authentication and not authorization. We simply return what the identity provider returns to us. We do not do any custom API requests to get the additional data requested. You can use the returned OAuth access token to call the Google APIs to get the additional requested data. You are welcome to file an official feature request and make a case for this.

@ForbiddenEra
Copy link
Author

Firebase Auth is focused on authentication and not authorization. We simply return what the identity provider returns to us. We do not do any custom API requests to get the additional data requested. You can use the returned OAuth access token to call the Google APIs to get the additional requested data. You are welcome to file an official feature request and make a case for this.

So, my inference was correct; and essentially now that I need to use another library just to get that extra tidbit -> I may as well completely ditch firebase and use that library to perform auth: the extra overhead of JS (see the issue re: firebase size) is not worth it; my use-case for firebase was being able to do social logins -> part of that is being able to get basic social user data.

This is after 2 frustrating days debugging and figuring out why it could not be implemented on an XHTML site; due to closure creating tags with uppercase letters. It was NOT immediately obvious from the documentation (hence creation of the issue) that this isn't possible.

@ForbiddenEra
Copy link
Author

Let's be clear also that my use-case is far less concerned with using firebase for actual auth's as it is just being able to provide social logins. I don't need firebase to store currently logged in users, or auth'd users, or anything. I simply wanted an easy way to add social logins and it works perfectly for this and I was going to allow it to manage our logged in users and email/pass accounts as well simply to keep it all under one system per-say but I still need to manage a local database of users as we need to store additional details, another feature that would make auth better is being able to store whatever data we need to associated with a user account without having to use any other firebase stuff.

@ForbiddenEra
Copy link
Author

Also; with several FR's in this tracker; why am I being requested to post a feature request directly to a form where it gets swallowed up into a private email somewhere instead of just being posted publicly where someone interested (such as myself) could potentially make a pull request to make it happen?

IF people simply report feature requests directly instead of posting here, is not only perhaps the FB team aware of it? Does this not discourage contribution?

@samtstern
Copy link
Contributor

@ForbiddenEra thanks for all your feedback. I totally understand how having to use a few libraries to get user information is annoying to you! That said I think the tone of your feedback is not very helpful, @bojeil-google has tried to explain to you that Firebase Authentication is probably not the best tool for your requirements. Nobody wants to force you to use Firebase if you're not happy with the way it works!

Since you don't seem to need the user storage that Firebase Auth offers or the ability to secure other Firebase resources (like Realtime Database, etc) then maybe you want to use a more generic OAuth library to get your user information? There are many good ones out there.

As I said earlier your requests for features are reasonable, however we have discussed these things in the past and have determined that we won't add them to Firebase Auth right now. Since this issue tracker is meant to track bugs in the SDK or feature requests that we plan to implement, I am going to close this issue.

@ForbiddenEra
Copy link
Author

@samtstern No tone - tone is a property of sound/spoken language not written word - but I am understandably frustrated that I've wasted days of time (again, because of another issue, presented here and in closure - that is IMHO absolutely insane that this issue went to production code) trying to implement something that appears to be right within the use-cases presented by the documentation; my use case is perfectly supported by firebase and allows me to use firebase exactly how I need to; so long as the auth provider craps out that information on the first request.

It was posted in the size issue that auth is a gateway use-case for firebase; for us it certainly was and again does 99.99% of everything we need in a way that we don't mind - I can imagine MANY people using firebase-auth like this and perhaps wanting to use other parts of the library. I was going to look into it, I did not mind having firebase manage all my auth including user/password and do not mind how it does it, in fact since I have already implemented it, for my time to not have been wasted my only option IS now to either modify firebase (not hard, since I've already had to use a local version) to pull the extra tidbit or load another huge library to do it.

The sad part is -> firebase already loads a ton of libraries from closure in it's compilation that I can't really use. Libraries I could use to make said extra request; again issue #332 ..

console.log(goog)
ReferenceError: goog is not defined

In that issue, you ask developers for their use-cases. I presented that there, and here. I'm FAR from the only user only interested in firebase-auth so when you say "since you don't seen to need anything else firebase offers" you're shunning all those users away too. It's not that I don't need or want to use the user storage with auth, I do, as I said, I'd like to use it for user/pass auth as well, but it seems silly to do that and still have to store user data locally especially if that user data belongs to the user and should be auth'd by the user before use - perhaps this is a usecase for firebase db but at least allowing some additional fields in the user database would be great.

Again - I'm mostly frustrated because firebase is implemented and working exactly how I need for my application 99.5% minus those two things, getting small additional details about the user from the auth provider (which imho is not out-of-scope) and storing additional data about the user (which I can live with since I have to have a local db for other things)

@firebase firebase locked and limited conversation to collaborators Oct 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants