Todas as integrações de notificações push iOS começam no mesmo ponto: provar ao serviço de Notificação Push da Apple que você tem permissão para enviar mensagens aos utilizadores da sua aplicação. A Apple oferece duas formas de o fazer — uma chave de autenticação APNs (.p8) ou um certificado APNs (.p12) — e a diferença entre elas é a diferença entre uma credencial que configura uma vez e outra que renovará anualmente, muitas vezes no pior momento possível.
Este guia explica como funciona a autenticação APNs, quando usar uma chave .p8 em vez de um certificado .p12 e o punhado de erros que remontam a fazer isto incorretamente.
Como funciona a autenticação APNs
Quando o seu fornecedor de push — PushEngage, ou o seu próprio servidor — envia uma notificação, liga-se à API do fornecedor APNs da Apple e tem de provar duas coisas: que está autorizado a enviar em seu nome e que tem permissão para direcionar o ID de pacote da sua aplicação (o "tópico" em termos APNs). A chave .p8 e o certificado .p12 são apenas duas formas diferentes de o provar.
O lado do dispositivo é separado. A sua aplicação regista-se com a APNs e recebe um token de dispositivo — essa parte nunca muda, independentemente da credencial que o seu fornecedor utiliza. A autenticação é puramente uma preocupação do servidor para a Apple, razão pela qual pode mudar de método sem tocar no binário da sua aplicação.
A chave de autenticação .p8 (use esta)
O .p8 é uma chave de assinatura de token. O seu fornecedor utiliza-a para emitir Tokens Web JSON de curta duração que autenticam cada ligação à APNs. As suas propriedades tornam-na a escolha padrão para quase todos:
- Nunca expira. Sem renovação anual, sem interrupção de push numa data esquecida.
- Uma chave cobre todas as aplicações na sua conta de desenvolvedor. Lance uma segunda aplicação e a mesma chave autentica-a.
- Funciona tanto para ambientes de desenvolvimento como de produção — sem pares de certificados sandbox/produção.
- Viaja como três valores: o ficheiro .p8 em si, o ID da Chave de 10 caracteres e o seu ID de Equipa.
Duas coisas a saber antes de criar uma. A Apple limita-o a duas chaves APNs ativas por conta, pelo que organizações grandes devem tratar a criação de chaves como um ato deliberado, não um hábito por projeto. E o ficheiro .p8 só pode ser descarregado uma vez, no momento da criação — guarde-o num local onde a sua equipa o possa encontrar, porque a Apple não o fornecerá novamente.
O certificado .p12 (o caminho legado)
O .p12 é um certificado de cliente TLS, exportado do Acesso às Chaves após a Apple o emitir. Autentica a própria ligação em vez de assinar tokens. Ainda funciona, e algumas políticas de segurança empresarial ainda o exigem, mas as suas restrições são a razão pela qual a Apple direciona novas integrações para a chave:
- Expira anualmente. A causa mais comum de falha súbita e total de push é um certificado APNs que expirou silenciosamente.
- Está limitado a uma única app. Cada ID de bundle necessita do seu próprio certificado, e cada certificado necessita do seu próprio calendário de renovação.
- Requer um Mac. A exportação de pedidos de assinatura e do Keychain não tem um caminho apenas através do navegador.
Qual deve usar?
| Chave de autenticação .p8 | Certificado .p12 | |
|---|---|---|
| Expira | Nunca | A cada 12 meses |
| Âmbito | Todas as apps na conta | Um ID de bundle |
| Ambientes | Desenvolvimento + produção | Separados ou combinados por certificado |
| Criado a partir de | Qualquer navegador | Mac com Acesso ao Keychain |
| Limite da conta | 2 chaves ativas | Pares por app |
| Usar quando | Quase sempre | A política exige certificados |
A resposta honesta: use a chave .p8 a menos que uma política de segurança force o caminho do certificado. Menos partes móveis, nada a renovar, uma credencial para todo o seu portfólio.
Criar uma chave .p8 em três minutos
- Na sua conta de Desenvolvedor Apple, vá a Certificados, Identificadores e Perfis → Chaves e registe uma nova chave.
- Dê-lhe um nome, ative a caixa de verificação Serviço de Notificações Push da Apple (APNs) e continue.
- Descarregue o ficheiro .p8 (lembre-se: uma oportunidade), e anote o ID da Chave mostrado no ecrã de confirmação e o seu ID da Equipa da página de adesão à conta.
- Carregue os três valores para o seu fornecedor de push. No PushEngage, este é um único ecrã nas configurações da sua app — o guia de credenciais APNs percorre-o com capturas de ecrã.
Os erros que isto explica
Uma percentagem surpreendente de tickets de “push está quebrado” são problemas de credenciais a disfarçar-se. Os suspeitos habituais:
- BadDeviceToken — está a enviar o token de uma aplicação criada em sandbox através do ambiente de produção, ou vice-versa. Compilações de depuração do Xcode comunicam com a sandbox; compilações do TestFlight e da App Store comunicam com a produção.
- TopicDisallowed — a credencial não cobre o ID do pacote que está a visar. Típico com certificados .p12 por aplicação e uma configuração copiada e colada.
- Falha súbita de entrega de 100% — um .p12 expirado. Verifique a data de expiração do certificado antes de verificar qualquer outra coisa.
- InvalidProviderToken — uma chave .p8 revogada, ou o par errado de Key ID/Team ID juntamente com um ficheiro válido.
Onde isto se encaixa na sua integração
A credencial APNs é o primeiro passo de uma única sessão de configuração. Carregue o .p8 para o PushEngage uma vez, e tudo o que se segue — a integração com o SDK iOS 1.0, multimédia rica através da sua extensão de notificação, campanhas acionadas e a própria entrega — funciona com base nela sem mais cerimónias. Se vem do Firebase, a mesma chave que deu ao FCM funciona aqui, o que é parte da razão pela qual migrar do FCM no iOS é um projeto de uma tarde.
Para a camada de estratégia que vem após a configuração, comece com o guia de marketing push para aplicações. E quando estiver pronto para enviar, o guia completo de configuração iOS leva-o da credencial à primeira campanha em menos de uma hora.
