@David, l’auteur de la PR a répondu à mon commentaire, quel est ton avis là-dessus ?
Moi :
Cette PR semble résoudre le problème de l’absence de nom et d’e-mail ?
Auteur de la PR :
Non, malheureusement. Apple doit fournir un point de terminaison d’API REST pour récupérer le nom et l’e-mail, car ils ne transmettent actuellement ces informations qu’une seule fois lors d’une authentification réussie, et non lors des authentifications suivantes.
Est-ce qu’une seule fois lors de l’authentification initiale ne suffit pas pour nous ?
C’est mieux que rien, mais ce n’est toujours pas suffisant. Par exemple, si vous vous « connectez avec Apple », puis annulez sur l’écran « créer un compte ». Ou si vous liez un compte existant à Apple, puis décidez de créer un nouveau compte à la place. Espérons qu’Apple résoudra cela avant la fin de la version bêta
Existe-t-il une implémentation fonctionnelle de la fonctionnalité « Se connecter avec Apple » à ce stade ? Un site pour lequel je travaille sur une place de marché prévoit une application iOS, mais sans cette option, nous ne pouvons pas activer d’autres options d’authentification, sauf si nous voulons que notre application soit rejetée pour non-respect des directives de l’App Store.
N’hésitez pas à installer le plugin pour le tester, mais je ne sais pas si le problème est déjà résolu. Je ne recommande toutefois pas de l’utiliser en production tant qu’il n’est pas terminé ou, à tout le moins, validé par un développeur disposant du temps nécessaire pour confirmer les choses.
Je suis un grand partisan de cette fonctionnalité. J’aimerais beaucoup la voir intégrée nativement à Discourse, comme les autres options de connexion.
Je pense que vous ne pouvez pas récupérer ce type d’informations intentionnellement.
Afficher un bouton « Se connecter avec Apple » dans votre application ou sur votre site Web signifie que les utilisateurs peuvent se connecter ou s’inscrire en un seul tapotement en utilisant leur identifiant Apple existant, évitant ainsi de remplir des formulaires, de vérifier leurs adresses e-mail et de choisir des mots de passe. « Se connecter avec Apple » offre une nouvelle méthode plus privée pour se connecter simplement et rapidement aux applications et aux sites Web, tout en offrant aux utilisateurs une expérience de connexion cohérente et fiable, ainsi que la commodité de ne pas avoir à se souvenir de plusieurs comptes et mots de passe. Dans les cas où vous choisissez de demander un nom et une adresse e-mail, les utilisateurs ont la possibilité de garder leur adresse e-mail privée et de partager une adresse e-mail unique et aléatoire à la place.
Vous avez raison, la confidentialité est l’un des aspects clés de la connexion avec Apple, mais l’essentiel de votre citation est :
En supposant que les utilisateurs choisissent de nous fournir leur nom et leur adresse e-mail, nous nous attendrions à les recevoir du fournisseur à chaque connexion. Dans l’implémentation actuelle, cela ne se produit pas. Après la première authentification, nous ne recevons aucune information sur l’utilisateur.
Je ne pense pas que cela puisse être corrigé par l’auteur du gem ; c’est quelque chose qu’Apple devrait modifier. Je ne vois pas cela se produire de sitôt, alors peut-être devrons-nous simplement demander aux utilisateurs de saisir manuellement leur nom et leur adresse e-mail dans Discourse
J’ai réussi à faire fonctionner partiellement un fork du plugin de Robert/merefield (le fork consiste uniquement à passer à une copie du gem omniauth que j’ai construite à partir de la dernière source disponible sur GitHub). Cependant, sur mon Discourse de test (qui utilise HTTPS de bout en bout via ngrok), j’ai dû définir le paramètre de site « Cookies du site » sur (aucun) pour que l’authentification fonctionne. Avec ce paramètre désactivé, je peux créer un compte (même si j’ai fermé le formulaire d’inscription) et me reconnecter, mais je ne peux pas le faire si le paramètre est activé.
La trace d’appel (backtrace) d’une tentative de connexion échouée est ci-dessous :
Quelqu’un ici aurait-il des suggestions sur la manière dont je pourrais réécrire le plugin pour qu’il ne nécessite plus de désactiver ce paramètre de site pour que ses fonctions principales fonctionnent ? Le code de mon plugin se trouve à l’adresse https://github.com/sau226dev/discourse-sign-in-with-apple et le dernier code que j’ai utilisé pour reconstruire le gem omniauth devrait se trouver dans la même organisation GitHub.
Merci d’avance pour toute l’aide que vous pourrez apporter,
Le plugin fonctionnait dans une certaine mesure à l’origine, mais n’a pas reçu d’attention récemment en raison du problème décrit par David ci-dessus.
Jusqu’à ce que nous recevions une bonne nouvelle indiquant qu’Apple a résolu ce blocage fondamental (l’envoi du nom et de l’adresse e-mail à chaque tentative de connexion), il ne vaut pas la peine de maintenir ce code, à mon avis. Je ne pense pas qu’il y ait quoi que ce soit que vous puissiez faire pour contourner cela ? C’est pourquoi je n’ai même pas tenté de mettre à jour les dépendances. Le plugin échouerait aux tests de toute façon.
Ce n’est donc pas un plugin « officiellement publié » (sinon ce sujet ou un sujet similaire serait dans #plugin), et il est peu probable qu’il reçoive un quelconque support avant que cela ne se produise. Je serais ravi de le « finaliser » si ce problème était résolu et qu’Apple fournissait ces informations.
Il y a aussi un autre problème majeur, soit dit en passant : pour l’utiliser sur votre propre site, vous devez payer pour le programme développeur Apple afin d’accéder à la configuration sur les systèmes d’Apple. Cela risque de décourager de nombreux sites à faible budget, je pense, car l’inscription n’est pas gratuite ni à bas prix.
@orenwolf Cela (l’absence d’email/nom renvoyé lors des connexions suivantes) ne semblait pas poser problème. Je pense que j’ai pu fermer la fenêtre d’inscription et reprendre l’inscription avec les bonnes informations transmises. Comme je l’ai mentionné précédemment, j’ai pu me connecter avec Apple immédiatement après, sans aucun souci.
Le seul problème que j’ai rencontré était l’erreur CSRF, sauf si le paramètre du site mentionné ci-dessus était désactivé. Un problème potentiel est l’absence de champ nom dans le formulaire de connexion et le fait que le nom d’utilisateur corresponde à ce qui se trouve avant le signe @ dans l’email (toutefois, à mon avis, ces problèmes potentiels sont soit inexistants, soit facilement résolus par l’utilisateur).
En plus des commentaires de David ci-dessus, j’ai trouvé un sujet connexe sur le site de support développeur d’Apple qui a suscité une réponse officielle confirmant le problème :
Réponse officielle :
Bonjour aslkdjalksdjasdasd,
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 l’objet ASAuthorizationAppleIDCredential initial contenant les informations utilisateur jusqu’à ce que vous puissiez valider qu’un compte a été créé avec succès sur votre serveur.
Patrick
Comme le remarque un développeur :
Alors attendez… Si, pour une raison quelconque, la première redirection depuis Apple est perdue pour l’une des nombreuses raisons très courantes, alors nous avons perdu cet utilisateur de façon permanente, car il n’existe aucun autre moyen d’obtenir ses informations. Il n’y a AUCUN autre moyen d’obtenir ces informations ?
Et un autre :
Ou si quelque chose échoue en aval, nous aurons des clients qui se plaignent et le support leur dira d’aller sur le site Apple ID pour révoquer la permission, afin qu’ils puissent s’enregistrer correctement à nouveau. Je pense que cela constituera une mauvaise expérience et découragera les gens d’utiliser ce mécanisme de connexion s’ils commencent à rencontrer ce genre de problèmes.
Donc, je ne pense pas qu’il soit possible d’utiliser cela en production en toute sécurité, malheureusement. Cela serait un cauchemar pour le support.
Je suggère de mettre ce sujet en pause jusqu’à ce qu’Apple prenne conscience du problème qu’ils ont créé : dans leur tentative d’améliorer la sécurité, il semble qu’ils aient compromis excessivement la robustesse.
Apple a mis à jour sa page de développement « Se connecter avec Apple » pour inclure davantage d’informations sur la collecte des données, la gestion des données, etc.
J’ai ouvert une demande de fusion pour mettre à jour le gem omniauth-apple vers la dernière version, qui inclut ce commit et qui semble pouvoir résoudre le problème de non-réception de l’adresse e-mail de l’utilisateur à chaque connexion.
Pour tester cela, j’ai suivi l’article de blog recommandé pour configurer les identifiants, mais il y a deux points que je n’ai pas encore réussis à élucider :
Quel est le chemin de la redirection de l’URL de retour nécessaire pour configurer l’ID de service avec Apple ?
Comment obtenir le “fichier de vérification txt”, ou est-ce que cela n’est plus requis ? En cherchant un peu, j’ai trouvé des mentions indiquant que ce fichier était téléchargeable auprès d’Apple dans le cadre de la configuration de la communication par domaine/e-mail, mais cela ne semble plus être le cas :
Normalement, vous soumettez une PR après avoir testé avec succès quelque chose
Veuillez confirmer lorsque vous l’aurez fait.
Cela semble être une évidence, mais je serais plus encouragé si nous avions une déclaration d’Apple indiquant qu’ils envoient désormais un e-mail à chaque fois. Changer la version du gem ne résoudra pas le problème si Apple n’a pas réglé le problème de fond.
Je vais examiner ma configuration lorsque je me réabonnerai au programme Apple Developer, ce que je n’ai pas encore fait… (ce fiasco a été un peu décourageant, pour être honnête)
J’ai essayé de mettre à jour notre fork du plugin pour utiliser la dernière version d’omniauth-apple. (Notez que d’autres modifications sont nécessaires, pas seulement une mise à jour du numéro de version).
tl;dr : ça ne fonctionne toujours pas
J’ai réussi à le faire fonctionner sur mon bac à sable, mais il reste plusieurs problèmes :
Apple utilise une requête POST sur le callback. Ce n’est pas courant dans les implémentations OAuth car cela signifie que les cookies samesite=Lax ne seront pas envoyés avec la requête. Cela empêche Discourse de lire les cookies de session pendant le callback, ce qui déclenche une erreur CSRF.
Le contournement NON SÉCURISÉ consiste à désactiver cette sécurité en changeant les cookies de Discourse pour samesite=None.
L’utilisation d’une requête POST sans jeton CSRF déclenche également une autre mesure de sécurité dans le cœur du système.
Le contournement NON SÉCURISÉ consiste à supprimer cette ligne.
Je recevais une erreur 403 de la part d’Apple lorsque le gem omniauth récupérait les JWKs. Je soupçonne que l’en-tête Accept: n’est pas défini correctement, mais je ne l’ai pas vérifié.
Le contournement NON SÉCURISÉ consistait à coder les clés en dur.
Après tout cela, j’ai enfin réussi à me connecter avec Apple. Vous pouvez l’essayer sur https://sandbox.dtaylor.uk (je le laisserai fonctionner pendant quelques jours, mais veuillez ne rien entrer de sensible car c’est NON SÉCURISÉ).
Et ensuite… les adresses e-mail et les noms ne sont toujours inclus que lors de la première authentification. Vous pouvez essayer cela : connectez-vous avec Apple, annulez la création du compte, puis réessayez. La deuxième tentative sera sans vos informations.
Donc, en supposant qu’Apple ne changera rien de sitôt… comment pourrions-nous faire fonctionner cela ?
Pour (1) et (2), je pense que nous pourrions convertir le POST d’Apple en GET sans nuire à la sécurité. Lorsque nous recevons un POST sur le callback, nous rendons du JavaScript qui définit window.location='/auth/apple/callback?code=...&state=.... À partir de là, cela fonctionnerait comme n’importe quel autre fournisseur. Cependant, je pense qu’intercepter le POST nécessiterait des modifications de l’API principale.
Pour (3), je pense que cela pourrait probablement être corrigé avec un peu de travail dans le gem omniauth.
Mais nous sommes toujours bloqués sans nom/e-mail, donc je ne suis pas sûr que cela vaille la peine de résoudre ces autres problèmes
Merci d’avoir réessayé et pour votre analyse ! Peut-être qu’en soumettant un incident de support technique à Apple, on pourrait éclaircir les problèmes restants ? D’après mon expérience, ils sont plus enclins à proposer des solutions ou des contournements là-bas que sur les forums pour développeurs d’Apple.
