Os problemas 1 e 2 são causados por uma escolha deliberada de implementação da Apple. Portanto, não se trata realmente de um incidente técnico, e podemos contorná-los. O problema 3 está relacionado ao gem omniauth-apple, então podemos corrigi-lo.
O que precisamos da Apple é que ela inclua o nome/e-mail nos fluxos de autenticação subsequentes. Infelizmente, eles reconheceram o comportamento e afirmaram que funciona conforme projetado: https://forums.developer.apple.com/thread/121496
Isso se comporta corretamente: as informações do usuário são enviadas apenas no ASAuthorizationAppleIDCredential durante o primeiro cadastro do usuário. Logins subsequentes no seu aplicativo usando o “Entrar com Apple” com a mesma conta não compartilham nenhuma informação do usuário e retornarão apenas um identificador de usuário no ASAuthorizationAppleIDCredential. Recomenda-se que você armazene com segurança o ASAuthorizationAppleIDCredential inicial contendo as informações do usuário até que possa validar que uma conta foi criada com sucesso no seu servidor.
Mas fiquei curioso: alguém já viu outros sites usando o “Entrar com Apple”? Acredito ter visto apenas aplicativos nativos utilizando essa funcionalidade
Essa funcionalidade faz muito sentido para mim, já que nosso aplicativo iOS se conecta ao nosso site Discourse e o aplicativo não exige login para outros recursos.
É muito conveniente para os usuários fazer login por esse método, pois a maioria já está logada no dispositivo e o Apple Pay, usado para compras dentro do aplicativo, utiliza a mesma conta.
Na minha opinião, ainda faria sentido entrar em contato com o DTS da Apple sobre isso para ver o que eles sugerem como solução alternativa e também para dar a eles o feedback de que isso está causando problemas. (Infelizmente, não tenho conhecimento suficiente sobre o assunto para ter essa conversa com eles.)
Está longe de ser tão disseminado quanto Google/FB/etc, mas já vi em alguns lugares, como ebay.com, wordpress.com e kayak.com.
Eles podem usar uma API diferente, no entanto. Existe um script JS que você pode adicionar, mas suspeito que ele não se integre ao sistema OAuth mais genérico do Discourse:
Suspeito que o Kayak e o WordPress estejam armazenando em cache as informações do usuário da primeira tentativa de autenticação, conforme a recomendação da Apple.
Acho que essa provavelmente será a abordagem que precisaremos adotar, mas não é particularmente robusta (por exemplo, se a conexão com a rede for interrompida durante a primeira tentativa, ou se o Discourse for restaurado a partir de um backup, ou se o usuário alterar seu endereço de e-mail da Apple). E, na minha opinião, é ligeiramente pior do ponto de vista da privacidade (precisamos armazenar e-mails para usuários que ainda nem se cadastraram!)
Algo mudou recentemente relacionado ao ‘Entrar com Apple’?
Podemos certamente fazê-lo funcionar como está — será necessário alguns dias para contornar esses problemas. Mas, mesmo assim, continuaremos recebendo apenas e-mail e nome no primeiro login de todos.
Acho que eles refinaram um pouco, mas não consigo encontrar facilmente mudanças específicas.
Acho que receber um e-mail apenas uma vez não é um grande problema? Acredito que precisamos testar o que acontece quando você altera seu e-mail no e-mail da sua Apple ID?
vou adicionar à minha lista para deixar o plugin atualizado para que possamos testar. Se funcionar bem, podemos movê-lo para o núcleo com bastante facilidade.
Li este tópico 2 ou 3 vezes, mas não me lembro se vocês tentaram obter o e-mail a partir do token JWT fornecido.
É assim que eu faço no código nativo. Não tenho certeza se a API da web permite isso.
No primeiro login, você pode obter o e-mail diretamente em ASAuthorizationAppleIDCredential.email.
Para logins subsequentes, o e-mail pode ser encontrado se você decodificar os dados do JWT e obter o campo “email”.
Com isso, a funcionalidade pode ser implementada, certo?
O e-mail fornecido será aquele escolhido pelo usuário, pessoal ou aleatório.
É tão estranho, porque no nativo consegui fazer funcionar apenas usando a propriedade de e-mail do JWT.
Se não atualizarem a versão web para ser semelhante, a única solução pode ser gerar automaticamente um e-mail fictício (confirmado automaticamente) e permitir que o usuário altere depois, se quiser.
Isso significaria confiar no ID fornecido pela Apple, o que não é uma solução tão ruim, mas tem um certo cheiro .
Sabemos que conseguimos fazer isso funcionar. O que se torna complicado é:
Seu e-mail do Apple ID é jane.champion@somewhere.com
Você se cadastra no Discourse usando o Apple
Você altera seu e-mail do Apple ID para jane.row@somewhere.com
Você faz login no Discourse… e ainda acreditamos que você é jane.champion@somewhere.com
Suas notificações por e-mail no Discourse agora serão rejeitadas indefinidamente.
Não temos clareza sobre qual processo está em vigor quando os e-mails do Apple ID mudam e como podemos reagir a isso, se for possível.
Minha conclusão sobre isso é que… simplesmente convivemos com esse caso de borda e, pelo menos, os usuários podem optar por alterar seus e-mails no Discourse para casos de borda como este.
Eu diria que isso é certamente um candidato para ser incluído no Discourse. Devemos visar incorporar o código ao núcleo ou, pelo menos, empacotar o plugin para a próxima versão principal. (com certeza não a da próxima semana, hein )
Sim, podemos mover isso de plugin para o núcleo mais tarde com pouco esforço. Um problema é que é super difícil de configurar em comparação com Google, Facebook, etc.
Você precisa de uma conta de desenvolvedor da Apple (paga?) e tem que configurar vários tipos de verificação de domínio e certificados. Com um bom tutorial, certamente é viável.
vou adicionar à minha lista para deixar o plugin atualizado para que possamos testar. Se funcionar bem, podemos movê-lo para o núcleo com bastante facilidade.
Estou vendo o endereço de e-mail presente em cada autenticação.