Issues 1 and 2 are caused by a deliberate implementation choice from Apple. So it’s not really a technical incident, and we can work around them. Issue 3 is with the omniauth-apple gem, so we can fix it.
The thing we need from apple is to include the name/email in subsequent authentication flows. Unfortunately they have acknowledged the behaviour, and said that it works as designed Cannot get email & name while … | Apple Developer Forums
This behaves correctly, user info is only sent in the ASAuthorizationAppleIDCredential upon initial user sign up. Subsequent logins to your app using Sign In with Apple with the same account do not share any user info and will only return a user identifier in the ASAuthorizationAppleIDCredential. It is recommened that you securely cache the initial ASAuthorizationAppleIDCredential containing the user info until you can validate that an account has succesfully been created on your server.
I am curious though, has anyone seen other websites using sign-in-with-apple? I think I’ve only seen native apps using it
This feature makes a lot of sense to me, where our iOS app links to our discourse web and the app doesn’t have any login requirements for the other features.
It’s very convenient for users to login using this method since most are already logged in on the device and Apple Pay used for in-app purchases uses the same account.
IMO it would still make sense to contact Apple DTS about this to see what they suggest as a workaround, and also to give them the feedback that this is causing issues. (Unfortunately I’m not knowledgeable enough about this myself to have that conversation with them.)
It’s far from being as pervasive as Google/FB/etc, but I’ve seen in a couple places, e.g. ebay.com, wordpress.com and kayak.com.
They are using apple’s javascript library, yes. But it’s still using the same ‘OAuth’ (but not really OAuth) API behind the scenes.
Ebay are not even trying to pull the user info. After signing in with apple you get asked for your email:
I suspect Kayak and Wordpress are caching user information from the first authentication attempt, per Apple’s recommendation.
I guess this is probably the approach we will need to take, but it’s not particularly robust (e.g. if network connection gets interrupted during the first attempt, or Discourse gets restored from a backup, or the user changes their apple email address). And, IMO, it is slightly worse from a privacy point of view (we have to store emails for users that haven’t even signed up yet!)
Did anything change related to Sign in with Apple recently?
We can certainly get it working as-is - it will require a few days of working around these issues. But then we’re still stuck only receiving email/name on the first ever login.
I read this topic 2-3 times but I don’t remember if you guys tried to get the email from jwt token provided.
This is how i do it in native code. I’m not sure if the web api allows this.
First login you can get the email directly from ASAuthorizationAppleIDCredential.email.
For subsequent logins, the email can be found if you decode the jwt data and get the “email” field.
With this the feature can be implemented right?
The email provided will be the one chosen by the user, personal or random.
It’s so weird, because on native i got it working just using the jwt email property.
If they don’t update it on web to be similar, the only solution may just be to automatically generate a dummy email (automatically confirmed) and let the user change it afterwards if he wants to.
This would mean relying on the id Apple provides, which is not that bad of a solution, but it does smell a bit.
I would say this is certainly a candidate for shipping with Discourse. We should aim to pull the code into core or at least bundle the plugin for the next major release. (certainly not the one next week though )
Yeah we can move it from plugin to core later with minimal effort. One problem is that it is mega-hard to configure when compared with google/facebook/etc.
You need a (paid?) apple developer account, and you have to configure all sorts of domain verification and certificates. It’s certainly achievable with a good howto though.
will add to my list to get the plugin up-to-scratch so we can test. If it works ok we can move it to core pretty easily.
I’m seeing the email address present in every authentication.