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

First and last name are nil #13

Closed
willc0de4food opened this issue Jan 3, 2020 · 7 comments
Closed

First and last name are nil #13

willc0de4food opened this issue Jan 3, 2020 · 7 comments

Comments

@willc0de4food
Copy link

Hello. I'm working on an implementation to use this gem with Devise, and everything is working. The problem I'm facing is that, although I'm requesting the user's name, and it shows up as something I'm requesting on the Apple oauth, the name is nil that gets returned from the gem. Is this a known issue? Any fix for it?

@sebfie
Copy link

sebfie commented Jan 6, 2020

+1

karlentwistle added a commit to karlentwistle/omniauth-apple that referenced this issue Feb 4, 2020
When providing both email and name as scopes. For example "email name" the
request URL is being incorrectly transformed with a + between the scope names
rather than correctly using a %20.

Incorrect: "name+email"
Correct: "name%20email"

@sebfie helpfully diagnosed the issue and figured out the fix here nhosoya#12 (comment)

I wondered if we could get this merged and released in the gem.

Closes nhosoya#12
Closes nhosoya#13
@jeffsawatzky
Copy link

This could be because you have already authorized the app. Apple only sends the user object the first time the user authorizes the app. Subsequent authorizations don't send the user object.

https://developer.apple.com/documentation/signinwithapplejs/configuring_your_webpage_for_sign_in_with_apple#3331292

The user object is what contains the first/last name.

Also, the id_token that apple gives out never seems to contain the first/name info, so that means the only time you can get this is the first time you authorize the app.

@willc0de4food
Copy link
Author

I am aware of this and tested multiple times deauthorize good the app. Never got the name.

@sdhull
Copy link

sdhull commented Mar 27, 2020

We seem to have observed an issue where if you authenticate with TouchID, then everything in the OmniAuth hash is nil (email, first name, last name), but if you authenticate with your Apple email & pw, everything is populated. We're still trying to figure it out, any help would be appreciated.

adamirowe pushed a commit to adamirowe/omniauth-apple that referenced this issue Mar 30, 2020
When providing both email and name as scopes. For example "email name" the
request URL is being incorrectly transformed with a + between the scope names
rather than correctly using a %20.

Incorrect: "name+email"
Correct: "name%20email"

@sebfie helpfully diagnosed the issue and figured out the fix here nhosoya#12 (comment)

I wondered if we could get this merged and released in the gem.

Closes nhosoya#12
Closes nhosoya#13
adamirowe pushed a commit to LeToteTeam/omniauth-apple that referenced this issue Mar 30, 2020
When providing both email and name as scopes. For example "email name" the
request URL is being incorrectly transformed with a + between the scope names
rather than correctly using a %20.

Incorrect: "name+email"
Correct: "name%20email"

@sebfie helpfully diagnosed the issue and figured out the fix here nhosoya#12 (comment)

I wondered if we could get this merged and released in the gem.

Closes nhosoya#12
Closes nhosoya#13
@rickstergg
Copy link

@sdhull , same thread as you, I'll share my findings if I come up with any, I had tried the scope encoding commit that references this issue, but we're still seeing the email coming up as null, will report back with any news!

fdocr added a commit to fdocr/omniauth-apple that referenced this issue Jul 31, 2020
When providing both email and name as scopes. For example "email name" the
request URL is being incorrectly transformed with a + between the scope names
rather than correctly using a %20.

Incorrect: "name+email"
Correct: "name%20email"

@sebfie helpfully diagnosed the issue and figured out the fix here nhosoya#12 (comment)

I wondered if we could get this merged and released in the gem.

Closes nhosoya#12
Closes nhosoya#13

Co-authored-by: Karl Entwistle <me@karlentwistle.com>
wilg added a commit to wilg/omniauth-apple that referenced this issue Feb 22, 2021
When providing both email and name as scopes. For example "email name" the
request URL is being incorrectly transformed with a + between the scope names
rather than correctly using a %20.

Incorrect: "name+email"
Correct: "name%20email"

@sebfie helpfully diagnosed the issue and figured out the fix here nhosoya#12 (comment)

I wondered if we could get this merged and released in the gem.

Closes nhosoya#12
Closes nhosoya#13

fdocr@366272a
@wilg wilg mentioned this issue Feb 22, 2021
@JonathanVeg
Copy link

I'm receiving the name as user e-mail. Looking in the gem it sets the name with user's email when the name do not came from apple validation.

I'm receiving it even in the first access (after removing the app from my account, having to accept and decide if I'll share my email or not).

Any solution? Thanks.

nov pushed a commit to wilg/omniauth-apple that referenced this issue Sep 26, 2022
When providing both email and name as scopes. For example "email name" the
request URL is being incorrectly transformed with a + between the scope names
rather than correctly using a %20.

Incorrect: "name+email"
Correct: "name%20email"

@sebfie helpfully diagnosed the issue and figured out the fix here nhosoya#12 (comment)

I wondered if we could get this merged and released in the gem.

Closes nhosoya#12
Closes nhosoya#13

fdocr@366272a
@nov
Copy link
Collaborator

nov commented Sep 27, 2022

hope this merged, or do the same in your app.
https://gitlab.com/oauth-xx/oauth2/-/merge_requests/633

@nov nov closed this as completed Sep 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants