Je pense que beaucoup de gens ont déjà entendu parler de Sign In with Apple (en abrégé SIWA) après la WWDC 2019. Dans cet article, je vais expliquer les pièges spécifiques que nous avons rencontrés lors de l'intégration de cette fonctionnalité dans notre portail licencié. Cet article n'est pas vraiment destiné à ceux qui viennent juste de décider de se familiariser avec SIWA (pour eux, j'ai fourni une série de liens d'introduction à la fin du texte). Dans ce matériel, beaucoup trouveront probablement des réponses aux questions qui peuvent se poser lors de l'intégration du nouveau service d'Apple.
Apple ne permet pas les redirections personnalisées
En réalité, je ne vois toujours pas de réponse à cette question sur les forums de développeurs. Voici le problème : si vous souhaitez utiliser l'API JS de SIWA, c'est-à-dire ne pas passer par le SDK natif en raison de l'absence de celui-ci pour diverses raisons (non macOS/iOS ou ancienne version de ces systèmes), alors vous avez besoin de votre propre portail public, sinon rien ne fonctionnera. En effet, sur le portail WWDR, vous devez enregistrer et confirmer que vous êtes le propriétaire de votre domaine, et c'est uniquement sur ce domaine que vous pouvez attacher des redirections acceptables selon Apple.
Que faire si vous souhaitez intercepter la redirection dans l'application ? Nous avons résolu ce problème de manière très simple : nous avons créé sur notre portail une liste de redirections acceptables pour nos applications, qui sont demandées avant d'afficher la page d'autorisation SIWA. Nous effectuons simplement une redirection de notre portail vers l'application avec les données obtenues d'Apple. Simple et efficace.
Problèmes avec l'e-mail
Voyons comment nous avons résolu les problèmes liés à l'e-mail de l'utilisateur. Tout d'abord, il n'existe pas d'API REST permettant d'obtenir ces informations depuis le backend — seul le client reçoit ces données et peut les transmettre avec le code d'autorisation.
Deuxièmement, les informations concernant le nom et l'e-mail de l'utilisateur ne sont transmises qu'une seule fois, lors de la première connexion de l'utilisateur à l'application via Apple, où l'utilisateur choisit les options de partage de ses données personnelles.
En soi, ces problèmes ne sont pas critiques si la connexion avec le profil social a été établie avec succès sur le portail — l'identifiant de l'utilisateur est le même et lié à l'ID de l'équipe, c'est-à-dire qu'il est unique pour toutes les applications de votre équipe intégrées à SIWA. Cependant, si la connexion a été effectuée via Apple et qu'une erreur s'est produite par la suite, empêchant la liaison sur le portail, la seule option est d'envoyer l'utilisateur sur appleid.apple.com, de rompre la connexion avec l'application et d'essayer à nouveau. En fait, le problème se résout en rédigeant un article de la KB approprié et en y ajoutant un lien.
Le problème suivant, plus désagréable, est que Apple a introduit un nouveau concept avec le proxy e-mail. Dans notre cas, si l'utilisateur était déjà sur le portail des licences avec son vrai e-mail et qu'il choisit l'option de masquer l'e-mail lors de la première connexion via Apple, un nouveau compte est créé avec ce proxy e-mail, qui, évidemment, ne contient aucune licence, ce qui met l'utilisateur final dans une situation délicate.
La solution à ce problème est assez simple : comme l'identifiant utilisateur est le même dans SIWA et ne dépend pas des options/application choisies pour se connecter, nous utilisons simplement un script spécial pour permettre de lier cette connexion Apple à un autre compte avec le vrai e-mail de l'utilisateur, et ainsi « restaurer ses achats ». Après cette procédure, l'utilisateur commence à accéder à un autre compte sur le portail via SIWA et tout fonctionne correctement.
Lors de la connexion via le portail web, l'icône de l'application n'apparaît pas.
Pour résoudre un autre problème, nous avons contacté les représentants d'Apple et partageons les connaissances obtenues :
C'est-à-dire que le principe est le suivant : à la tête du groupe SIWA, seule une application macOS/iOS peut être placée, dans laquelle les ID de service nécessaires des portails sont déjà ajoutés. Par conséquent, pour que l'icône apparaisse dans l'application principale, il doit y avoir des versions publiées dans l'App Store avec des médias, ayant passé la validation d'Apple. L'icône sera prise de là.
En conséquence, si vous n'avez qu'un portail et pas d'application de l'App Store, vous n'aurez pas d'icône attrayante, mais vous pouvez gérer avec le nom de l'application — en l'absence de médias dans l'application principale, cette information est tirée de la description de l'ID de service :
Le nombre d'éléments dans un groupe SIWA est limité à 5.
Il n'y a actuellement pas de solution à ce problème, à part utiliser de nombreux groupes. Si vous manquez de 6 identifiants : 1 identifiant principal et 5 dépendants, vous verrez ce message en essayant d'enregistrer le suivant :
Nous avons créé des groupes pour notre portail de licence et pour chacune des applications qui interagissent avec ce portail. Concernant la limitation des slots, nous avons déjà ouvert un ticket chez Apple et attendons leur réponse.
Liens utiles
Le plus utile , à mon avis, sur lequel j'ai essentiellement fait tout cela. Document à moitié utile d'Apple .
Profitez-en ! Les questions, réflexions, idées et suggestions sont les bienvenues dans les commentaires.
Source : habr.com
