Will Sign in with Apple be a supported sign in method when it reaches public availability later this year?
Nobody’s been assigned to it yet but I suspect it’ll happen if they gain traction. Even if we don’t do it quickly in discourse core I think it’s likely someone in the community will create a plugin.
12 Mi Piace
Cool. I hadn’t seen it mentioned anywhere yet, so thought I’d bring it up!
I could have a crack at this, given I just PR’d to the Discord one … how hard can it be? 
I also feel it’s important to support identity management with a company that is more privacy focussed that, ahem, others we could mention.
13 Mi Piace
Do it @merefield!
As there is a omniauth-apple strategy already it should be doable GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple
16 Mi Piace
Very useful, thanks Rafael
Siamo molto vicini alla soluzione, ma abbiamo incontrato un ostacolo:
La strategia OAuth richiede un file di chiave pem (che si ottiene da quelle persone gentili di Apple)
Quando provo a memorizzarlo in un SiteSetting, il testo viene in qualche modo corrotto e la generazione della chiave privata fallisce:
::OpenSSL::PKey::EC.new(options.pem)
# OpenSSL::PKey::ECError
## invalid curve name
Ho tentato di escapare il testo inserendo \n dove ci sono le interruzioni di riga.
Non riesco a vedere come possa essere deployabile a meno che non possiamo in qualche modo memorizzare il contenuto di questo file in un SiteSetting?
1 Mi Piace
Il file .pem è solo la chiave pubblica, vero?
In questo caso include la chiave privata (apparentemente sono codificate anche altre cose).
Il codice prosegue utilizzando questa chiave privata per generare il segreto del client.
Ho testato la libreria con il file PEM ed è valido, ma non appena incolli il file in un SiteSetting, viene (forse prevedibilmente) alterato in modo sottile.
AGGIORNAMENTO: sembra che \n venga sostituito con \\n nei SiteSettings, quindi si potrebbe cercare \\ al momento del recupero e ridurlo di uno.
Sembra che sia riuscito a risolvere, scusate per lo spam.
7 Mi Piace
Un aggiornamento:
Il mio plugin sembra funzionare fino a un certo punto, ma attualmente ricevo un errore vago da Apple quando provo ad autenticarmi con le credenziali che ho configurato come Sviluppatore Apple:
“La tua richiesta non è stata completata a causa di un errore. Riprova più tardi”
Come puoi immaginare, questo non mi offre molti indizi.
La situazione è leggermente complicata dal fatto che il loro schema di autorizzazione è molto diverso dallo standard OAuth 2.0.
Purtroppo non posso ancora aprire un ticket completo TSI con Apple perché la funzionalità è in pre-rilascio, ma invierò un problema di Feedback.
Il repository è qui:
NB: Usalo a tuo rischio e pericolo - non è stato ancora testato con successo!
7 Mi Piace
Forse usiamo un caricamento file per il file pem? Quanto è grande?
È minuscolo 
Il ‘file’ PEM (come stringa nelle Impostazioni del sito) sembra essere elaborato correttamente, quindi sembra che non sia più il problema.
Quell’errore originale è scomparso. JWT sembra elaborarlo correttamente ora.
L’ho risolto sostituendo le nuove righe con un segno , e poi sostituendo il segno con una nuova riga quando lo passo alla funzione JWT. Non è standard, ma funziona. Fornire ‘/’ crea problemi a causa di come Ruby lo gestisce. (Ammetto comunque che, anche se non viene generata alcuna eccezione, questo potrebbe comunque essere un punto critico)
Sei il benvenuto a usare le tue credenziali Apple e provarci.
Temo di aver sbagliato qualcosa con le credenziali.
Devi fornire:
- Team ID
- Client ID
- PEM
- Key ID
È molto complicato configurare tutto questo sul sito di Apple
8 Mi Piace
@merefield Ce l’ho fatto funzionare con successo su sandbox.dtaylor.uk 
Ho dovuto apportare alcune modifiche nel nostro fork per consentire la verifica del dominio. Ho anche aggiunto descrizioni più specifiche alle impostazioni del sito e abilitato il supporto per righe multiple per il PEM.
Sembra che il gem omniauth-apple non supporti (ancora?) il passaggio di informazioni sull’utente… il che non è particolarmente utile per noi. Sembra che sign-in-with-apple sia quasi compatibile con OpenID-Connect, quindi è possibile che potremmo essere in grado di riutilizzare alcune funzionalità di quel plugin.
Per quanto riguarda la configurazione delle credenziali, ho trovato questo post del blog (dal nome molto appropriato) molto più utile della documentazione di Apple:
11 Mi Piace
È fantastico! Ah, textarea è una novità per me. Evita in modo elegante il mio “hack” che avevo aggiunto. Perfetto! Se solo l’avessi saputo prima! 
Mi piace il controllo di verifica tramite file txt che hai aggiunto, un bel tocco. Lo facevo manualmente, ma è un grande aiuto per l’uso in produzione.
Sì, l’ho usato anch’io.
Purtroppo ricevo ancora lo stesso errore lato Apple dopo aver unito il tuo fork, quindi sospetto di stare ancora facendo qualcosa di sciocco con le credenziali. Potrei scriverti in privato se posso per scambiare due chiacchiere! 
7 Mi Piace
OK, sembra che il mio problema fosse quasi sicuramente dovuto al tentativo di accedere da un sito parzialmente in sviluppo (in esecuzione con nginx e tramite HTTPS).
Ho riprovato con un sito di produzione e
ma purtroppo, come dici tu, “Name” non viene restituito e questo deve essere colpa del middleware, giusto? Sembra che sia Apple a permettere questa autorizzazione.
Siamo sicuri che restituirà un nome? Da una prospettiva sulla privacy, è quasi meglio se l’utente sceglie un nome piuttosto che divulgare qualsiasi PII pubblica nel processo.
Tecnicamente dovrebbe farlo? Ma sono d’accordo con il tuo punto, anche se puoi scegliere di non esporlo nella pagina di Apple. Moot, a quanto pare finora!
Sì, qualcuno ha segnalato questo problema, ma è stato poi chiuso.
Immagino che questo sia l’area di codice che ci preoccupa:
info do
{ sub: id_token['sub'] }
end
mentre nel gem di autenticazione per Discord, ad esempio, otteniamo questo:
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
Per tua informazione, non c’è alcun riferimento a questi campi nella documentazione dell’API di Apple…
Sembra che questa PR aggiunga le utili informazioni sull’utente: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Speriamo venga unita presto, altrimenti potremmo valutare di utilizzare un fork.
5 Mi Piace
Sì, hai ragione: avevo visto quella PR, ma non avevo approfondito il codice e pensavo si trattasse semplicemente di passare a una dipendenza diversa. Le persone dovrebbero evitare di aprire PR con un ambito così vasto, perché dettagli come questo rischiano di andare persi.
Come hai detto:
{
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)
}
}
Ho aggiunto un commento a sostegno della PR.
4 Mi Piace