Elke iOS-pushmeldingintegratie begint bij dezelfde poort: Apple Push Notification service bewijzen dat u gemachtigd bent om uw app-gebruikers te berichten. Apple biedt u twee manieren om dit te doen — een APNs-authenticatiesleutel (.p8) of een APNs-certificaat (.p12) — en het verschil ertussen is het verschil tussen een credential die u eenmalig configureert en een die u jaarlijks zult vernieuwen, vaak op het slechtst mogelijke moment.
Deze handleiding legt uit hoe APNs-authenticatie daadwerkelijk werkt, wanneer u een .p8-sleutel versus een .p12-certificaat gebruikt, en de handvol fouten die terug te voeren zijn op het verkeerd instellen hiervan.
Hoe APNs-authenticatie werkt
Wanneer uw pushprovider — PushEngage, of uw eigen server — een melding verzendt, maakt deze verbinding met de APNs-provider-API van Apple en moet deze twee dingen bewijzen: dat deze gemachtigd is om namens u te verzenden, en dat deze gemachtigd is om de bundel-ID van uw app te targeten (het 'onderwerp' in APNs-termen). De .p8-sleutel en het .p12-certificaat zijn slechts twee verschillende manieren om dit te bewijzen.
De apparaatzijde is gescheiden. Uw app registreert zich bij APNs en ontvangt een apparaattoken — dat deel verandert nooit, ongeacht welke credential uw provider gebruikt. Authenticatie is puur een server-naar-Apple-aangelegenheid, daarom kunt u methoden wisselen zonder uw app-binaire bestand aan te raken.
De .p8-authenticatiesleutel (gebruik deze)
De .p8 is een sleutel voor het ondertekenen van tokens. Uw provider gebruikt deze om kortstondige JSON Web Tokens te genereren die elke verbinding met APNs authenticeren. De eigenschappen maken het de standaardkeuze voor bijna iedereen:
- Deze verloopt nooit. Geen jaarlijkse vernieuwing, geen pushonderbreking op een vergeten datum.
- Eén sleutel dekt elke app in uw ontwikkelaarsaccount. Breng een tweede app uit en dezelfde sleutel authenticeert deze.
- Deze werkt voor zowel ontwikkelings- als productieomgevingen — geen sandbox/productiecertificaatparen.
- Deze wordt geleverd als drie waarden: het .p8-bestand zelf, de 10-cijferige sleutel-ID en uw Team-ID.
Twee dingen om te weten voordat u er een aanmaakt. Apple beperkt u tot twee actieve APNs-sleutels per account, dus grote organisaties moeten het aanmaken van sleutels behandelen als een bewuste handeling, niet als een gewoonte per project. En het .p8-bestand kan slechts één keer worden gedownload, op het moment van aanmaken — bewaar het ergens waar uw team het kan vinden, want Apple zal het u niet nogmaals geven.
Het .p12-certificaat (het legacy-pad)
De .p12 is een TLS-clientcertificaat, geëxporteerd uit Sleutelhangertoegang nadat Apple het heeft uitgegeven. Het authenticeert de verbinding zelf in plaats van tokens te ondertekenen. Het werkt nog steeds, en sommige bedrijfsbeveiligingsbeleidsregels vereisen het nog steeds, maar de beperkingen ervan zijn de reden waarom Apple nieuwe integraties naar de sleutel stuurt:
- Deze verloopt elk jaar. De meest voorkomende oorzaak van plotselinge, totale pushfouten is een APNs-certificaat dat stilzwijgend is verlopen.
- Het is beperkt tot één app. Elke bundel-ID heeft een eigen certificaat nodig, en elk certificaat heeft een eigen vernieuwingskalender nodig.
- Het vereist een Mac. De ondertekeningsverzoek-en-Sleutelhangerexport-dans heeft geen browser-optie.
Welke moet je gebruiken?
| .p8-authenticatiesleutel | .p12-certificaat | |
|---|---|---|
| Vervalt | Nooit | Elke 12 maanden |
| Bereik | Alle apps in het account | Eén bundel-ID |
| Omgevingen | Ontwikkeling + productie | Gescheiden of gecombineerd per certificaat |
| Gemaakt van | Elke browser | Mac met Sleutelhangertoegang |
| Accountlimiet | 2 actieve sleutels | Per-app-paren |
| Gebruik wanneer | Bijna altijd | Beleid vereist certificaten |
Het eerlijke antwoord: gebruik de .p8-sleutel, tenzij een beveiligingsbeleid het certificaatpad afdwingt. Minder bewegende delen, niets te vernieuwen, één inloggegevens voor uw hele portfolio.
Een .p8-sleutel maken in drie minuten
- Ga in uw Apple Developer-account naar Certificaten, Identificaties en Profielen → Sleutels en registreer een nieuwe sleutel.
- Geef het een naam, schakel het selectievakje Apple Push-meldingsservice (APNs) in en ga verder.
- Download het .p8-bestand (onthoud: één kans), en noteer de Sleutel-ID die op het bevestigingsscherm wordt weergegeven en uw Team-ID van de accountlidmaatschapspagina.
- Upload alle drie de waarden naar uw pushprovider. In PushEngage is dit een enkel scherm in uw app-instellingen — de APNs-inloggegevensgids leidt u er met screenshots doorheen.
De fouten die dit verklaart
Een verrassend groot deel van de "push is kapot" tickets zijn inloggegevensproblemen die zich vermommen. De gebruikelijke verdachten:
- BadDeviceToken — je stuurt een token van een sandbox-gebouwde app via de productieomgeving, of andersom. Debug builds van Xcode praten met de sandbox; TestFlight en App Store builds praten met productie.
- TopicDisallowed — de inloggegevens dekken niet de bundle ID die je target. Typisch met per-app .p12 certificaten en een gekopieerde configuratie.
- Plotselinge 100% leveringsfout — een verlopen .p12. Controleer de vervaldatum van het certificaat voordat je iets anders controleert.
- InvalidProviderToken — een ingetrokken .p8 sleutel, of het verkeerde Key ID/Team ID paar naast een geldig bestand.
Waar dit past in je integratie
De APNs-inloggegevens zijn stap één van precies één installatiesessie. Upload de .p8 eenmalig naar PushEngage, en alles wat daarna komt — de iOS SDK 1.0 integratie, rich media via je notification extension, getriggerde campagnes, en de levering zelf — draait ertegenaan zonder verdere ceremonie. Als je van Firebase komt, werkt dezelfde sleutel die je aan FCM gaf hier ook, wat mede verklaart waarom migreren van FCM op iOS een middagproject is.
Voor de strategielaag die na de installatie komt, begin met de app push marketing gids. En als je klaar bent om te verzenden, de volledige iOS installatiegids leidt je van inloggegevens naar de eerste campagne in minder dan een uur.
