Ik denk dat velen Sign In with Apple (afgekort SIWA) na WWDC 2019 al hebben gehoord. In het materiaal zal ik je vertellen met welke specifieke valkuilen ik te maken kreeg bij het integreren van dit ding in ons gelicentieerde portaal. Dit artikel is niet helemaal voor degenen die net besloten hebben om met SIWA in zee te gaan (voor hen heb ik aan het einde van de tekst een aantal inleidende links gegeven). In dit materiaal zullen hoogstwaarschijnlijk velen antwoorden vinden op vragen die kunnen rijzen bij het integreren van een nieuwe Apple-service.
Apple staat geen aangepaste omleidingen toe
Eigenlijk zie ik het antwoord op deze vraag nog steeds niet op de ontwikkelaarsforums. Het komt erop neer: als u de SIWA JS API wilt gebruiken, d.w.z. werkt niet via de native SDK door het ontbreken ervan om de een of andere reden (niet macOS/iOS of de oude versie van deze systemen), dan heb je een eigen publieke portal nodig, anders niets. Omdat u zich op de WWDR-portal moet registreren en moet bevestigen dat u de eigenaar van uw domein bent, en alleen omleidingen die geldig zijn vanuit het standpunt van Apple, kunnen eraan worden gekoppeld:
Wat te doen als er een wens is om de omleiding in de applicatie te onderscheppen? We hebben dit probleem heel eenvoudig opgelost: we hebben een lijst met geldige omleidingen voor onze applicaties op ons portaal gemaakt, die ze bestellen voordat de SIWA-autorisatiepagina wordt weergegeven. En we doen gewoon een omleiding van de portal naar de applicatie met de gegevens die we van Apple hebben ontvangen. Simpel en boos.
Problemen met e-mail
Laten we eens kijken hoe we problemen met de e-mail van de gebruiker hebben opgelost. Ten eerste is er geen REST API waarmee u deze informatie uit de backend kunt halen - alleen de client ontvangt deze gegevens en kan deze samen met de autorisatiecode doorgeven.
Ten tweede wordt informatie over de naam en het e-mailadres van de gebruiker slechts één keer verzonden, namelijk bij de allereerste aanmelding van de gebruiker bij de applicatie via Apple, waar de gebruiker opties selecteert voor het delen van zijn persoonlijke gegevens.
Op zichzelf zijn deze problemen niet direct kritiek als de verbinding met het sociale profiel met succes op de portal tot stand is gebracht - de gebruikers-ID is dezelfde en is gekoppeld aan de team-ID - d.w.z. het is hetzelfde voor alle applicaties van uw team die zijn geïntegreerd met SIWA. Maar als de login is gemaakt via Apple, en verderop in het proces is er een fout opgetreden en de verbinding op de portal is niet gemaakt, dan is de enige optie om de gebruiker naar appleid.apple.com te sturen, de verbinding met de applicatie te verbreken en probeer het nog eens. Eigenlijk wordt het probleem opgelost door het overeenkomstige KB-artikel te schrijven en ernaar te linken.
Het volgende vervelendere probleem is dat Apple met een nieuw concept kwam met e-mailproxy. In ons geval, als de gebruiker al op het gelicentieerde portaal was met zijn echte soap en bij de eerste login via Apple de optie selecteert om e-mail te verbergen, wordt een nieuw account geregistreerd met deze proxy-e-mail, die uiteraard geen bevat eventuele licenties, waardoor de eindgebruiker op een dood spoor komt te zitten.
De oplossing voor dit probleem is vrij simpel: de user-ID is hetzelfde in SIWA en is niet afhankelijk van de geselecteerde opties/applicatie waarin de login is gemaakt, dan gebruiken we gewoon een speciaal script om deze verbinding met Apple om te zetten naar een ander account met een echte user soap en daarmee “ herstel uw aankopen ". Na deze procedure begint de gebruiker via SIWA toegang te krijgen tot een ander account op het portaal en alles werkt correct voor hem.
Wanneer u zich aanmeldt via het webportaal, is er geen toepassingspictogram
Om een ander probleem op te lossen, wendden we ons tot Apple-vertegenwoordigers voor opheldering, we delen onze kennis:
Die. de betekenis is als volgt: aan het hoofd van de SIWA-groep, m.b. alleen de macOS/iOS-applicatie is geleverd, waaraan de benodigde service-ID's van de portalen al zijn toegevoegd. Dienovereenkomstig zou het moeten zijn om het pictogram voor de hoofdtoepassing weer te geven. In de App Store gepubliceerde versies met door Apple geverifieerde media. Het pictogram wordt vanaf daar overgenomen.
Dienovereenkomstig, als je alleen een portal hebt en geen applicaties uit de App Store, dan zal er geen mooi pictogram zijn, maar je kunt eruit komen met de naam van de applicatie - als de hoofdapplicatie geen media heeft, is deze informatie afkomstig van de Beschrijving service-ID:
Het aantal elementen in een SIWA-groep is beperkt tot 5
Dit probleem heeft op dit moment geen oplossing, behalve het gebruik van meerdere groepen, als u 6 ID's mist: 1 bovenliggende applicatie en 5 personen ten laste, en wanneer u de volgende probeert te registreren, ziet u dit bericht:
We hebben groepen gemaakt voor ons licentieportaal en voor elk van de applicaties die op dit portaal werken. Wat betreft de slotlimiet, we zijn al een radar gestart bij Apple en wachten op hun reactie.
Nuttige links
Meest nuttig , naar mijn mening, volgens welke ik eigenlijk alles deed. Het semi-nuttige dock van Apple .
Genieten! Vragen, gedachten, ideeën en suggesties worden geaccepteerd in de commentaren.
Bron: www.habr.com