Les problèmes 1 et 2 sont dus à un choix d’implémentation délibéré de la part d’Apple. Il ne s’agit donc pas vraiment d’un incident technique, et nous pouvons les contourner. Le problème 3 concerne le gem omniauth-apple, nous pouvons donc le corriger.
Ce dont nous avons besoin d’Apple, c’est qu’ils incluent le nom et l’adresse e-mail dans les flux d’authentification ultérieurs. Malheureusement, ils ont reconnu ce comportement et indiqué qu’il fonctionne comme prévu : https://forums.developer.apple.com/thread/121496
Ce comportement est correct : les informations utilisateur ne sont envoyées dans ASAuthorizationAppleIDCredential que lors de l’inscription initiale de l’utilisateur. Les connexions ultérieures à votre application via « Se connecter avec Apple » avec le même compte ne partagent aucune information utilisateur et ne renvoient qu’un identifiant utilisateur dans ASAuthorizationAppleIDCredential. Il est recommandé de mettre en cache de manière sécurisée le ASAuthorizationAppleIDCredential initial contenant les informations utilisateur, jusqu’à ce que vous puissiez valider qu’un compte a été créé avec succès sur votre serveur.
Je suis cependant curieux : quelqu’un a-t-il déjà vu d’autres sites web utiliser « Se connecter avec Apple » ? À ma connaissance, je n’ai vu que des applications natives l’utiliser
Cette fonctionnalité me semble très logique, étant donné que notre application iOS renvoie vers notre site web Discourse et que l’application ne nécessite aucune connexion pour les autres fonctionnalités.
Il est très pratique pour les utilisateurs de se connecter avec cette méthode, car la plupart sont déjà connectés sur l’appareil, et Apple Pay, utilisé pour les achats intégrés, utilise le même compte.
À mon avis, il serait tout de même logique de contacter le DTS d’Apple à ce sujet pour voir ce qu’ils suggèrent comme solution de contournement, et aussi pour leur faire part du fait que cela pose des problèmes. (Malheureusement, je ne suis pas assez compétent sur ce sujet pour avoir cette conversation avec eux.)
C’est loin d’être aussi répandu que Google, Facebook, etc., mais je l’ai vu sur quelques sites, par exemple ebay.com, wordpress.com et kayak.com.
Ils utilisent peut-être une API différente. Il existe un script JS que vous pouvez ajouter, mais je doute qu’il s’intègre au système OAuth plus générique de Discourse :
Je soupçonne Kayak et WordPress de mettre en cache les informations de l’utilisateur dès la première tentative d’authentification, conformément aux recommandations d’Apple.
Je suppose que c’est probablement l’approche que nous devrons adopter, mais elle n’est pas particulièrement robuste (par exemple, si la connexion réseau est interrompue lors de la première tentative, si Discourse est restauré à partir d’une sauvegarde, ou si l’utilisateur modifie son adresse e-mail Apple). Et, à mon avis, c’est légèrement pire d’un point de vue de la confidentialité (nous devons stocker les adresses e-mail d’utilisateurs qui n’ont même pas encore créé de compte !)
Quelque chose a-t-il changé récemment concernant la connexion avec Apple ?
Nous pouvons bien sûr le faire fonctionner tel quel, mais cela nécessitera quelques jours pour contourner ces problèmes. Cependant, nous resterons alors limités à la réception de l’adresse e-mail et du nom uniquement lors de la toute première connexion.
Je pense qu’ils l’ont un peu affiné, mais je ne peux pas facilement retrouver des changements spécifiques.
Je pense que recevoir un seul e-mail n’est pas un problème majeur ? Je suppose qu’il faut tester ce qui se passe lorsque vous changez votre adresse e-mail sur votre compte Apple ID ?
Nous devrions continuer à recevoir le même UID, mais nous ne recevrons pas la nouvelle adresse e-mail. L’utilisateur devra la mettre à jour manuellement dans Discourse.
Je suppose qu’on devrait vérifier cela deux fois, mais honnêtement, je ne vois pas cela comme un énorme drame qui nous empêcherait de mettre cela en œuvre.
Le flux de connexion sur les appareils i est tout simplement incroyable avec la connexion via Apple, et vous bénéficiez en plus de la double authentification avec Face ID.
je l’ajouterai à ma liste pour mettre le plugin à niveau afin que nous puissions le tester. Si tout fonctionne correctement, nous pourrons facilement le déplacer dans le cœur du système.
J’ai lu ce sujet 2 à 3 fois, mais je ne me souviens pas si vous avez essayé d’extraire l’adresse e-mail du jeton JWT fourni.
Voici comment je procède en code natif. Je ne suis pas sûr que l’API web le permette.
Lors de la première connexion, vous pouvez obtenir l’adresse e-mail directement via ASAuthorizationAppleIDCredential.email.
Pour les connexions suivantes, l’adresse e-mail peut être retrouvée si vous décodez les données du jeton JWT et récupérez le champ « email ».
Avec cela, la fonctionnalité peut-elle être implémentée ?
L’adresse e-mail fournie sera celle choisie par l’utilisateur, personnelle ou aléatoire.
C’est vraiment étrange, car sur la version native, cela fonctionne simplement en utilisant la propriété email du JWT.
S’ils ne mettent pas à jour la version web pour qu’elle soit similaire, la seule solution pourrait consister à générer automatiquement un faux e-mail (automatiquement confirmé) et à permettre à l’utilisateur de le modifier ensuite s’il le souhaite.
Cela signifierait s’appuyer sur l’ID fourni par Apple, ce qui n’est pas une si mauvaise solution, mais cela sent un peu le roussi .
Nous savons que nous pouvons faire fonctionner cela. Ce qui se complique, c’est :
Votre adresse e-mail Apple ID est jane.champion@somewhere.com
Vous vous inscrivez sur Discourse avec Apple
Vous modifiez votre adresse e-mail Apple ID pour jane.row@somewhere.com
Vous vous connectez à Discourse … nous pensons toujours que vous êtes jane.champion@somewhere.com
Vos notifications par e-mail sur Discourse rebondiront désormais indéfiniment.
Nous ne sommes pas clairs sur le processus en place lorsque les adresses e-mail Apple ID changent et sur la manière dont nous pouvons y réagir, si possible.
Mon avis à ce sujet est que… nous vivons simplement avec ce cas limite et, au moins, les utilisateurs peuvent choisir de modifier leurs adresses e-mail dans Discourse pour des cas limites comme celui-ci.
J’ai fait des tests aujourd’hui, et la bonne nouvelle, c’est qu’il semble qu’Apple ait corrigé le problème Je vois l’adresse e-mail présente dans chaque authentification.
Il reste encore quelques problèmes à résoudre, mais j’espère pouvoir publier quelque chose cette semaine.
Je dirais que c’est certainement un candidat à être livré avec Discourse. Nous devrions viser à intégrer le code dans le cœur ou, à défaut, à inclure le plugin dans la prochaine version majeure (en tout cas pas celle de la semaine prochaine, bien sûr :)).
Oui, on pourra le déplacer du plugin vers le cœur plus tard avec un effort minime. Un problème, c’est que la configuration est extrêmement difficile par rapport à Google, Facebook, etc.
Il faut un compte développeur Apple (payant ?) et configurer toute une série de vérifications de domaine et de certificats. C’est certainement réalisable avec un bon guide pas à pas.
je l’ajouterai à ma liste pour mettre le plugin à niveau afin que nous puissions le tester. Si tout fonctionne correctement, nous pourrons facilement le déplacer dans le cœur du système.
Je vois l’adresse e-mail présente dans chaque authentification.