Entrar com Apple

Contribuir Funcionalidade
1

O recurso ‘Entrar com Apple’ será um método de login suportado quando for disponibilizado publicamente mais tarde neste ano?

16 curtidas
2019: The Year in Review
2

Ninguém foi designado para isso ainda, mas suspeito que isso acontecerá se ganharem tração. Mesmo que não o façamos rapidamente no núcleo do Discourse, acredito que é provável que alguém da comunidade crie um plugin.

12 curtidas
3

Legal. Eu não tinha visto isso mencionado em lugar nenhum ainda, então achei que seria bom trazer à tona!

4

Eu poderia tentar isso, já que acabei de fazer um PR para o do Discord… quão difícil pode ser? :wink:

Também acho importante apoiar a gestão de identidade com uma empresa mais focada na privacidade do que, hum, outras que poderíamos mencionar.

13 curtidas
5

Faça isso, @merefield!

Como já existe uma estratégia omniauth-apple, deve ser possível: GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple · GitHub

16 curtidas
6

Muito útil, obrigado, Rafael

7

Estamos muito perto disso agora, mas encontramos um obstáculo:

A estratégia OAuth requer um arquivo de chave pem (que você obtém daquela gente legal da Apple)

Quando tento armazenar isso em uma SiteSetting, o texto de alguma forma é corrompido e a geração da chave privada falha:

::OpenSSL::PKey::EC.new(options.pem)

# OpenSSL::PKey::ECError

## invalid curve name

Tentei escapar o texto com \n onde há quebras de linha.

Não vejo como isso possa ser implantável a menos que possamos de alguma forma armazenar o conteúdo desse arquivo em uma SiteSetting.

1 curtida
8

O .pem é apenas a chave pública, não é?

9

Neste caso, inclui a chave privada (aparentemente há outras coisas codificadas nela).

O código continua usando essa chave privada para gerar o segredo do cliente.

Testei a biblioteca com o arquivo PEM e ele é válido, mas assim que você cola o arquivo em um SiteSetting, ele (talvez previsivelmente) é sutilmente alterado.

ATUALIZAÇÃO: parece que \n é substituído por \\n nos SiteSettings, então talvez seja possível procurar por \\ ao recuperar e reduzi-lo em um.

Parece que consegui resolver, desculpe pelo spam.

7 curtidas
10

Uma atualização:

Meu plugin parece estar funcionando até certo ponto, porém, estou recebendo um erro genérico da Apple ao tentar autenticar com as credenciais que configurei como Desenvolvedor Apple:

“Sua solicitação não pôde ser concluída devido a um erro. Tente novamente mais tarde”

Como você pode imaginar, isso não me dá muito o que trabalhar.

Isso é um pouco agravado porque o esquema de autorização deles é bastante diferente do padrão OAuth 2.0.

Infelizmente, ainda não consigo abrir um ticket completo de suporte técnico (TSI) com a Apple, pois o recurso está em fase pré-lançamento, mas vou enviar um relatório de Feedback.

O repositório está aqui:

AVISO: Use por sua conta e risco — ainda não testado com sucesso!

7 curtidas
11

Talvez usemos um upload de arquivo para o arquivo pem? Qual é o tamanho dele?

12

É minúsculo :slight_smile:

O “arquivo” PEM (como uma string nas Configurações do Site) parece ser processado corretamente, então isso não parece mais ser o problema.

Esse erro original desapareceu. O JWT parece processá-lo corretamente agora.

Eu resolvi substituindo as quebras de linha por um sinal de cifrão (), e depois substituindo o por uma quebra de linha ao passá-lo para a função JWT. Não é padrão, mas funciona. Fornecer ‘/’ causa problemas devido à forma como o Ruby lida com isso. (Eu admito, no entanto, que, embora nenhuma exceção seja lançada, isso ainda pode ser uma área problemática)

Você é mais do que bem-vindo a usar suas credenciais da Apple e testar.

Eu temo que tenha cometido algum erro com as credenciais.

Você precisa fornecer:

  • Team ID
  • Client ID
  • PEM
  • Key ID

É muito complicado configurar tudo isso no site da Apple :slight_smile:

8 curtidas
13

@merefield Consegui executá-lo com sucesso no sandbox.dtaylor.uk :tada:

Fui obrigado a fazer algumas alterações no nosso fork para permitir a verificação de domínio. Também adicionei descrições mais específicas às configurações do site e habiliti o suporte a múltiplas linhas para o PEM.

Parece que o gem omniauth-apple ainda não suporta o envio de qualquer informação sobre o usuário… o que não é particularmente útil para nós. Parece que o sign-in-with-apple é quase compatível com OpenID-Connect, então é possível que possamos reutilizar parte da funcionalidade desse plugin.

Em termos de configuração das credenciais, achei este post de blog (com um nome muito apropriado) muito mais útil do que a documentação da Apple:

11 curtidas
14

Isso é ótimo! Ah, textarea é novo para mim. Isso evita perfeitamente a minha ‘gambiarra’ que eu adicionei. Perfeito! Se eu soubesse disso antes! :sweat_smile:

Gosto da verificação de arquivo txt que você adicionou, ótimo toque. Eu fazia isso manualmente, mas isso é uma grande ajuda para uso em produção.

Sim, eu usei esse também.

Infelizmente, ainda estou recebendo o mesmo erro do lado da Apple após mesclar seu fork, então suspeito que ainda estou fazendo algo bobo com as credenciais. Posso te enviar uma mensagem privada se puder para trocar ideias! :wink:

7 curtidas
15

Ok, descobri que meu problema quase certamente era tentar acessar um site parcialmente em desenvolvimento (rodando com nginx e via HTTPS).

Tentei novamente com um site de Produção e :tada:

mas, infelizmente, como você disse, o “Nome” não é retornado, e isso deve ser culpa do middleware, certo? Parece que a Apple está permitindo que você autorize isso.

16

Temos certeza de que isso retornará um nome? Do ponto de vista da privacidade, é quase melhor que o usuário escolha um nome do que ter qualquer PII pública divulgada no processo.

17

Tecnicamente, deveria retornar, certo? Mas concordo com seu ponto, embora você possa optar por não expô-lo na página da Apple. Moot, como acabou sendo até agora!

18

Sim, alguém havia levantado uma questão sobre isso, mas ela foi então fechada.

Comentei sobre isso

Estou supondo que este seja o trecho de código que nos preocupa?:

      info do
        { sub: id_token['sub'] }
      end

enquanto na gem de autenticação do Discord, por exemplo, obtemos isso:

      info do
        {
          name: raw_info['username'],
          email: raw_info['verified'] ? raw_info['email'] : nil,
          image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
        }
      end

FYI Não há menção desses campos na documentação da API da Apple …

19

Parece que este PR adiciona informações úteis do usuário: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Esperamos que seja mesclado em breve, ou, se não, podemos considerar usar um fork.

5 curtidas
20

Sim, você tem razão. Eu vi aquele PR, mas não mergulhei no código e achei que se tratava apenas de mudar para uma dependência diferente. As pessoas deveriam considerar não enviar PRs com escopo tão grande, pois detalhes como esse podem se perder.

Como você disse:

        {
          sub: id_info['sub'],
          email: user_info.dig('email'),
          first_name: user_info.dig('name', 'firstName'),
          last_name: user_info.dig('name', 'lastName'),
          extra: {
            raw_info: id_info.merge(user_info)
          }
        }

Adicionei um comentário para apoiar o PR.

4 curtidas