No profile info when logging in via GitHub? [solved^2]

Hi, I’m getting back this:


when signing in via GitHub. (The user id, 44111668, is correct).

I use github.scope="user:email".

1. Do you know why username, full name and email is not included in the response from GitHub?

2. Or maybe field names have changed somehow and something gets lost?
(well, everything except for the user id / some user specific number)

3. I’m wondering if I should to a request to: GET /user/emails and look at the list of the user’s email addresses, to see if there’s any primary & verified address. — Is that maybe how things are supposed to be done, with GitHub?


You should only use the scope read:user. The email address in the profile result is the public visible email address of the user. You could find more information in the user API doc.

The doc says, that user:email grants only read access to a user’s email addresses.

Best regards

1 Like

Hi Christian! Thanks! Now I understand how everything works, and was able to proceed and get things working.

Ok, read:user works, … except that CommonSocialProfile in discards the GitHub username (and other interesting things like the GitHub profile page). So I still get the same “meaningless” empty C.S.P. as the one above.

I’ll open another topic about maybe amending the C.S.P. with more commonly used fields? (username makes sense in many cases?)

Actually I need user:email too (in addition to read:user). I need a preferably verified & primary email address, to send notification emails to … and in some cases, no email address at all is included in the read:user JSON response fields — then, I now call the /user/email GitHub API endpoint and in that way get the primary email address (also if it’s private).

For such things you can write a new profile builder.

1 Like

Thanks! That’s precisely what I was looking for, e.g.: “developers can mix in a profile builder which adds only the programming logic for the additional fields”

About this: “Every profile builder must define a profile parser, which transforms the content returned
from the provider into a social profile instance. Parsers can then be reused by other
parsers to avoid code duplication.”
— that’s great. I restructured my code, to make use of that. Also I’m glad that the functions support async code, i.e. return Future[...] — thanks to that, I could do the async request to GitHub and fetch the email address, from inside my CustomGitHubProfileParser.