Enhver iOS-pushnotifikationsintegration starter ved den samme port: at bevise over for Apple Push Notification service, at du har tilladelse til at sende beskeder til din apps brugere. Apple giver dig to måder at gøre det på — en APNs-godkendelsesnøgle (.p8) eller et APNs-certifikat (.p12) — og forskellen mellem dem er forskellen mellem en legitimationsoplysning, du konfigurerer én gang, og en, du vil forny hvert år, ofte på det værst tænkelige tidspunkt.
Denne guide forklarer, hvordan APNs-godkendelse rent faktisk fungerer, hvornår du skal bruge en .p8-nøgle versus et .p12-certifikat, og de få fejl, der kan spores tilbage til at få dette forkert.
Sådan fungerer APNs-godkendelse
Når din push-udbyder — PushEngage eller din egen server — sender en notifikation, opretter den forbindelse til Apples APNs-udbyder-API og skal bevise to ting: at den er autoriseret til at sende på dine vegne, og at den har tilladelse til at målrette din apps bundt-id (emnet i APNs-termer). .p8-nøglen og .p12-certifikatet er blot to forskellige måder at bevise det på.
Enhedssiden er separat. Din app registrerer sig hos APNs og modtager en enhedstoken — den del ændrer sig aldrig, uanset hvilken legitimationsoplysning din udbyder bruger. Godkendelse er udelukkende et anliggende mellem server og Apple, hvilket er grunden til, at du kan skifte metoder uden at røre din app-binærfil.
Godkendelsesnøglen .p8 (brug denne)
.p8 er en nøgle til signering af tokens. Din udbyder bruger den til at oprette kortlivede JSON Web Tokens, der godkender hver forbindelse til APNs. Dens egenskaber gør den til standardvalget for næsten alle:
- Den udløber aldrig. Ingen årlig fornyelse, ingen push-nedetid på en glemt dato.
- Én nøgle dækker alle apps i din udviklerkonto. Udgiv en anden app, og den samme nøgle godkender den.
- Den fungerer til både udviklings- og produktionsmiljøer — ingen par af sandbox/produktionscertifikater.
- Den overføres som tre værdier: selve .p8-filen, den 10-cifrede nøglen ID og dit Team ID.
To ting, du skal vide, før du opretter en. Apple begrænser dig til to aktive APNs-nøgler pr. konto, så store organisationer bør behandle nøgleoprettelse som en bevidst handling, ikke en vane pr. projekt. Og .p8-filen kan kun downloades én gang, ved oprettelsestidspunktet — gem den et sted, hvor dit team kan finde den, for Apple giver dig den ikke igen.
Certifikatet .p12 (den ældre vej)
.p12 er et TLS-klientcertifikat, eksporteret fra Nøgleringadgang, efter at Apple har udstedt det. Det godkender selve forbindelsen i stedet for at signere tokens. Det fungerer stadig, og nogle virksomhedssikkerhedspolitikker kræver det stadig, men dets begrænsninger er grunden til, at Apple styrer nye integrationer mod nøglen:
- Det udløber hvert år. Den mest almindelige årsag til pludselig, total push-fejl er et APNs-certifikat, der stille og roligt er udløbet.
- Det er omfanget til en enkelt app. Hvert bundt-id kræver sit eget certifikat, og hvert certifikat kræver sin egen fornyelseskalender.
- Det kræver en Mac. Signeringsanmodnings- og nøglerings-eksportdansen har ingen browser-kun sti.
Hvilken skal du bruge?
| .p8-godkendelsesnøgle | .p12-certifikat | |
|---|---|---|
| Udløber | Aldrig | Hver 12. måned |
| Omfang | Alle apps i kontoen | Et bundt-id |
| Miljøer | Udvikling + produktion | Adskilt eller kombineret pr. certifikat |
| Oprettet fra | Enhver browser | Mac med Nøgleringsadgang |
| Kontobegrænsning | 2 aktive nøgler | Par pr. app |
| Brug når | Næsten altid | Politik kræver certifikater |
Det ærlige svar: brug .p8-nøglen, medmindre en sikkerhedspolitik tvinger certifikatstien. Færre bevægelige dele, intet at forny, én legitimationsoplysning for hele din portefølje.
Oprettelse af en .p8-nøgle på tre minutter
- Gå i din Apple Developer-konto til Certifikater, Identifikatorer & Profiler → Nøgler og registrer en ny nøgle.
- Navngiv den, aktiver afkrydsningsfeltet Apple Push Notifications service (APNs), og fortsæt.
- Download .p8-filen (husk: én chance), og noter Nøgle-ID vist på bekræftelsesskærmen og dit Team-ID fra medlemskabssiden for kontoen.
- Upload alle tre værdier til din push-udbyder. I PushEngage er dette en enkelt skærm i dine appindstillinger — APNs-legitimationsguide guider dig igennem den med skærmbilleder.
De fejl, dette forklarer
En overraskende stor del af “push er ødelagt”-billetter er legitimationsproblemer, der er forklædt. De sædvanlige mistænkte:
- BadDeviceToken — du sender en token fra en sandbox-bygget app gennem produktionsmiljøet, eller omvendt. Debug-builds fra Xcode taler til sandboxen; TestFlight og App Store-builds taler til produktionen.
- TopicDisallowed — legitimationsoplysningerne dækker ikke det bundt-id, du målretter mod. Typisk med per-app .p12-certifikater og en kopieret konfiguration.
- Pludselig 100% leveringsfejl — en udløbet .p12. Kontroller certifikatets udløbsdato, før du kontrollerer noget andet.
- InvalidProviderToken — en tilbagekaldt .p8-nøgle, eller den forkerte Key ID/Team ID-par sammen med en gyldig fil.
Hvor dette passer ind i din integration
APNs-legitimationsoplysningerne er trin ét ud af præcis én opsætningssession. Upload .p8 til PushEngage én gang, og alt efterfølgende — iOS SDK 1.0-integrationen, rich media via din udvidelse til notifikationer, udløste kampagner og selve leveringen — kører mod den uden yderligere ceremoni. Hvis du kommer fra Firebase, virker den samme nøgle, som du gav FCM, her, hvilket er en del af grunden til, at migrering fra FCM på iOS er et eftermiddagsprojekt.
For strategilaget, der kommer efter opsætningen, start med guiden til app push-marketing. Og når du er klar til at sende, tager den komplette guide til iOS-opsætning dig fra legitimationsoplysninger til den første kampagne på under en time.
