L’option « Se connecter avec Apple » sera-t-elle une méthode de connexion prise en charge lorsqu’elle sera disponible publiquement plus tard cette année ?
Personne n’a encore été assigné à cela, mais je soupçonne que cela arrivera s’ils gagnent en traction. Même si nous ne le faisons pas rapidement dans le noyau de Discourse, je pense qu’il est probable que quelqu’un dans la communauté crée un plugin.
12 « J'aime »
Cool. Je ne l’avais encore vu mentionné nulle part, alors j’ai pensé que je devais en parler !
Je pourrais essayer de m’en charger, puisque je viens de soumettre une contribution pour celui de Discord… comment ça pourrait être difficile ? 
Je pense aussi qu’il est important de soutenir la gestion des identités avec une entreprise plus axée sur la confidentialité que, euh, d’autres que nous pourrions mentionner.
13 « J'aime »
Fais-le @merefield !
Comme il existe déjà une stratégie omniauth-apple, cela devrait être faisable : GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple · GitHub
16 « J'aime »
Très utile, merci Rafael
On y est presque, mais j’ai rencontré un problème :
La stratégie OAuth nécessite un fichier de clé pem (que vous obtenez auprès de ces aimables personnes chez Apple).
Lorsque j’essaie de le stocker dans un SiteSetting, le texte est somehow corrompu et la génération de la clé privée échoue :
::OpenSSL::PKey::EC.new(options.pem)
# OpenSSL::PKey::ECError
## nom de courbe invalide
J’ai essayé d’échapper le texte avec \n là où il y a des sauts de ligne.
Je ne vois pas comment cela peut être déployable à moins que nous puissions d’une manière ou d’une autre stocker le contenu de ce fichier dans un SiteSetting.
1 « J'aime »
Le fichier .pem est simplement la clé publique, n’est-ce pas ?
Dans ce cas, cela inclut la clé privée (apparemment, d’autres éléments y sont encodés).
Le code utilise ensuite cette clé privée pour générer le secret du client.
J’ai testé la bibliothèque avec le fichier PEM et il est valide, mais dès que vous collez le fichier dans un SiteSetting, il est (ce qui est peut-être prévisible) subtilement altéré.
MISE À JOUR : il semble que \n soit remplacé par \\n dans les SiteSettings, il serait donc peut-être possible de rechercher \\ lors de la récupération et de le réduire d’un.
Il semble que j’aie pu régler le problème, désolé pour le spam.
7 « J'aime »
Une mise à jour :
Mon plugin semble fonctionner jusqu’à un certain point, mais je rencontre actuellement une erreur vague de la part d’Apple lorsque j’essaie de m’authentifier avec les identifiants que j’ai configurés en tant que développeur Apple :
“Votre demande n’a pas pu être complétée en raison d’une erreur. Veuillez réessayer plus tard.”
Comme vous pouvez l’imaginer, cela ne me donne pas beaucoup d’éléments pour avancer.
La situation est légèrement aggravée par le fait que leur système d’autorisation diffère considérablement de la norme OAuth 2.0.
Malheureusement, je ne peux pas encore ouvrir un ticket TSI complet auprès d’Apple car la fonctionnalité est en préversion, mais je soumettrai un rapport de problème via Feedback.
Le dépôt est disponible ici :
NB : À utiliser à vos propres risques – pas encore testé avec succès !
7 « J'aime »
Peut-être utilisons-nous un téléchargement de fichier pour le fichier pem ? Quelle est sa taille ?
C’est minuscule 
Le « fichier » PEM (en tant que chaîne dans les paramètres du site) semble être traité correctement, donc cela ne semble plus être le problème.
L’erreur initiale a disparu. JWT semble maintenant le traiter sans problème.
Je l’ai résolu en remplaçant les sauts de ligne par un signe , puis en remplaçant le signe par un saut de ligne lors de son passage à la fonction JWT. Ce n’est pas standard, mais cela fonctionne. Fournir « / » pose problème à cause de la manière dont Ruby le gère. (J’admets cependant que, même si aucune exception n’est levée, cela pourrait toujours être une source de problème)
Vous êtes tout à fait libre d’utiliser vos identifiants Apple et de l’essayer.
Je crains qu’il y ait une erreur de ma part avec les identifiants.
Vous devez fournir :
- Team ID
- Client ID
- PEM
- Key ID
C’est très fastidieux de configurer tout cela sur le site d’Apple
8 « J'aime »
@merefield Je l’ai fait fonctionner avec succès sur sandbox.dtaylor.uk 
J’ai dû apporter quelques modifications dans notre fork pour permettre la vérification de domaine. J’ai également ajouté des descriptions plus précises aux paramètres du site et activé le support des lignes multiples pour le PEM.
Il semble que le gem omniauth-apple ne prenne pas (encore ?) en charge le passage d’informations sur l’utilisateur… ce qui n’est pas très utile pour nous. Il semble que sign-in-with-apple soit presque compatible avec OpenID-Connect, il est donc possible que nous puissions réutiliser certaines fonctionnalités de ce plugin.
En ce qui concerne la configuration des identifiants, j’ai trouvé cet article de blog (très bien nommé) bien plus utile que la documentation d’Apple :
11 « J'aime »
C’est super ! Ah, textarea est nouveau pour moi. Cela évite élégamment mon « hack » que j’avais ajouté. Parfait ! Si seulement je l’avais su ! 
J’aime bien la vérification du fichier txt que tu as ajoutée, c’est une belle touche. Je le faisais manuellement, mais c’est une aide précieuse pour les déploiements.
Oui, je l’ai utilisé aussi.
Malheureusement, j’obtiens toujours la même erreur côté Apple après avoir fusionné ton fork, donc je soupçonne que je fais encore une bêtise avec les identifiants. Je pourrais te MP si tu es d’accord pour échanger des informations !
7 « J'aime »
OK, il s’avère que mon problème venait presque certainement d’une tentative d’accès via un site en développement partiel (exécuté avec nginx et via HTTPS). J’ai réessayé avec un site de production et Mais malheureusement, comme vous le dites, le champ « Nom » n’est pas renvoyé, et cela doit provenir du middleware, n’est-ce pas ? Cela ressemble à Apple qui vous autorise à faire cette autorisation.
Sommes-nous certains que cela renverra un nom ? D’un point de vue confidentialité, il est presque préférable que l’utilisateur choisisse un nom plutôt que de divulguer des données personnelles identifiables (PII) publiques dans le processus.
Cela devrait fonctionner techniquement ? Mais je suis d’accord avec votre remarque, même si vous pouvez choisir de ne pas l’exposer sur la page d’Apple. Muet, comme il s’avère jusqu’à présent !
Oui, quelqu’un a signalé un problème à ce sujet, mais il a ensuite été clos.
J’ai laissé un commentaire dessus
Je suppose qu’il s’agit de la zone de code qui nous intéresse ? :
info do
{ sub: id_token['sub'] }
end
alors que dans le gem d’authentification Discord, par exemple, nous obtenons cela :
info do
{
name: raw_info['username'],
email: raw_info['verified'] ? raw_info['email'] : nil,
image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
}
end
Pour information, aucune mention de ces champs dans la documentation de l’API d’Apple …
Il semble que cette PR ajoute des informations utilisateur utiles : Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Espérons qu’elle sera fusionnée bientôt, ou sinon, nous pourrions envisager d’utiliser un fork.
5 « J'aime »
Oui, vous avez raison, j’avais vu cette PR mais je n’avais pas creusé le code et j’avais pensé qu’il s’agissait simplement de passer à une autre dépendance. Les personnes devraient éviter de proposer des PR d’une ampleur aussi importante, car des détails comme celui-ci peuvent être perdus.
Comme vous l’avez dit :
{
sub: id_info['sub'],
email: user_info.dig('email'),
first_name: user_info.dig('name', 'firstName'),
last_name: user_info.dig('name', 'lastName'),
extra: {
raw_info: id_info.merge(user_info)
}
}
J’ai ajouté un commentaire pour soutenir la PR.
4 « J'aime »