@David, l’autore della PR ha risposto al mio commento, qual è la tua opinione al riguardo?:
Io:
Questa PR sembra risolvere il problema della mancanza di nome ed email?
Autore della PR:
No, purtroppo no. Apple deve fornire un endpoint REST API per recuperare nome ed email, poiché attualmente passano queste informazioni solo al momento di un’autenticazione riuscita e non nelle autenticazioni successive.
Non è sufficiente averle una sola volta all’autorizzazione iniziale?
È meglio di niente, ma non è ancora buono. Ad esempio, se fai “accesso con Apple”, ma poi annulli nella schermata “crea account”. Oppure se colleghi un account esistente con Apple, poi decidi di creare un nuovo account invece. Speriamo che Apple risolva il problema prima della fine della beta 
Esiste al momento un’implementazione funzionante della funzionalità ‘Accedi con Apple’? Un sito per cui sto lavorando su un marketplace prevede di avere un’app iOS; tuttavia, senza questa opzione, non possiamo abilitare altre modalità di autenticazione a meno che non vogliamo rischiare il rifiuto dell’app per violazione delle linee guida dell’App Store.
No, per quanto ne sappia. Stiamo aspettando che questo problema venga risolto How to retrieve email and name? · Issue #8 · nhosoya/omniauth-apple · GitHub, anche se il proprietario del repository lo ha chiuso in modo poco utile.
Non ne sono troppo sicuro, ma non risolvono il problema commit come questo e gli altri commit di agosto?
Sentiti libero di installare il plugin per testarlo, ma non sono a conoscenza di una risoluzione al momento. Non lo consiglierei per l’ambiente di produzione fino a quando non sarà completato o almeno approvato da uno sviluppatore che abbia il tempo di verificare tutto.
Sono un grande sostenitore di questa funzionalità. Mi piacerebbe vederla integrata nel Discourse vanilla, proprio come le altre opzioni di accesso.
Credo che non sia possibile recuperare quel tipo di informazioni per scelta.
Mostrare un pulsante “Accedi con Apple” nella tua app o sul tuo sito web significa che le persone possono accedere o registrarsi con un semplice tocco, utilizzando l’ID Apple che già possiedono, evitando di compilare moduli, verificare indirizzi email e scegliere password. Accedi con Apple offre un nuovo metodo più privato per accedere in modo semplice e rapido alle app e ai siti web, garantendo un’esperienza di accesso coerente di cui ci si può fidare e la comodità di non dover ricordare più account e password. Nei casi in cui scegli di richiedere nome e indirizzo email, gli utenti hanno la possibilità di mantenere privato il proprio indirizzo email e condividere invece un indirizzo email univoco e casuale.
Hai ragione, la privacy è uno degli aspetti fondamentali di ‘Accedi con Apple’, ma la parte chiave della tua citazione è:
Assumendo che gli utenti scelgano di fornirci nome e indirizzo email, ci aspetteremmo di riceverli dal provider ogni volta che l’utente effettua il login. Nell’implementazione attuale, questo non accade. Dopo la prima autenticazione, non riceviamo più alcuna informazione sull’utente.
Non credo che questo sia un problema che l’autore del gem possa risolvere: è qualcosa che Apple dovrebbe modificare. Non vedo che accada in tempi brevi, quindi forse dovremo semplicemente chiedere agli utenti di inserire manualmente nome e indirizzo email su Discourse 
Sì, ma cosa succede per coloro che alla fine scelgono di non fornire le proprie informazioni?
Oh, e ecco un concetto grezzo. 
Buone notizie:
Sono riuscito a far funzionare parzialmente un fork del plugin di Robert/merefield (il fork consiste solo nel passare a una copia del gem omniauth che ho compilato dall’ultima versione disponibile su GitHub). Tuttavia, sul mio Discourse di test (che utilizza HTTPS end-to-end tramite ngrok), ho dovuto impostare l’opzione “Cookie del sito” nelle Impostazioni del sito su (nessuno) affinché l’autenticazione funzionasse. Con questa impostazione disabilitata, riesco a creare un account (anche se ho chiuso il modulo di registrazione) e a effettuare nuovamente il login; però, se l’impostazione è abilitata, non riesco a farlo.
Di seguito il backtrace di un tentativo di accesso fallito:
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:112:in `report_to_store'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:103:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:54:in `add'
/usr/local/lib/ruby/2.6.0/logger.rb:543:in `error'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:163:in `log'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:486:in `fail!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-oauth2-1.6.0/lib/omniauth/strategies/oauth2.rb:71:in `callback_phase'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:238:in `callback_call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:192:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/omniauth-1.9.0/lib/omniauth/builder.rb:64:in `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:47:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/tempfile_reaper.rb:15:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/conditional_get.rb:38:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/head.rb:12:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:318:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/session/abstract/id.rb:259:in `context'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/session/abstract/id.rb:253:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/cookies.rb:648:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/callbacks.rb:27:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/callbacks.rb:101:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/callbacks.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/actionable_exceptions.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/debug_exceptions.rb:32:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/middleware/reporter.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/rack/logger.rb:38:in `call_app'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/rack/logger.rb:28:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:18:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/request_id.rb:27:in `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/method_override.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/executor.rb:14:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/sendfile.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/host_authorization.rb:77:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-mini-profiler-1.1.4/lib/mini_profiler/profiler.rb:184:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-2.2.3/lib/message_bus/rack/middleware.rb:57:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:181:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:526:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/urlmap.rb:68:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/urlmap.rb:53:in `each'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rack-2.0.8/lib/rack/urlmap.rb:53:in `call'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:605:in `process_client'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:700:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:548:in `spawn_missing_workers'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:144:in `start'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'
Qualcuno ha suggerimenti su come o se posso riscrivere il plugin in modo che non richieda più la disabilitazione di questa impostazione del sito per far funzionare le sue funzioni principali? Il codice del mio plugin si trova su https://github.com/sau226dev/discourse-sign-in-with-apple e l’ultima versione utilizzata per ricompilare il gem omniauth dovrebbe essere nella stessa organizzazione GitHub.
Grazie in anticipo per qualsiasi aiuto possiate fornire,
sau226
Il plugin funzionava in una certa misura all’inizio, ma non ha ricevuto attenzione di recente a causa del problema descritto da David sopra.
Finché non riceveremo notizie positive sul fatto che Apple abbia risolto quel blocco fondamentale (l’invio di nome ed email ad ogni tentativo di accesso), non vale la pena mantenere questo codice, a mio avviso. Non credo ci sia nulla che si possa fare per aggirarlo? Ecco perché non ho nemmeno tentato di aggiornare le dipendenze. In ogni caso, il plugin fallirebbe i test.
Quindi questo non è un plugin ‘rilasciato’ (altrimenti questo o un argomento simile sarebbe presente in #plugin) e è improbabile che riceva supporto fino a quando ciò non accadrà. Sarei felice di ‘rifinirlo’ se quel problema venisse risolto e Apple fornisse quelle informazioni.
C’è anche un’altra questione significativa, tra l’altro: per utilizzarlo sul proprio sito è necessario pagare l’iscrizione al Programma Apple Developer per accedere alla configurazione sui sistemi di Apple. Questo, temo, dissuaderà molti siti con budget limitato, dato che non si tratta di un’iscrizione gratuita o a basso costo.
Credo che @sau226 sembri suggerire che la mancanza di e-mail/nome restituiti non sia, in realtà, un blocco?
@orenwolf Il problema (la mancanza di email/nome restituiti nei successivi accessi) non sembrava esserci. Credo di essere stato in grado di chiudere la finestra di registrazione e riprendere la procedura inserendo i dettagli corretti. Come ho già detto, sono riuscito ad accedere immediatamente con Apple senza alcun problema.
L’unico problema che ho riscontrato è stato l’errore CSRF, a meno che non venga disabilitata l’impostazione del sito che ho menzionato sopra. Un potenziale problema è l’assenza del campo nome nel modulo di accesso e il fatto che il nome utente sia tutto ciò che precede il simbolo @ nell’email (tuttavia, a mio avviso, questi potenziali problemi sono o irrilevanti o possono essere facilmente risolti dall’utente).
Oltre ai commenti di David sopra riportati, ho trovato un argomento correlato sul sito di supporto per sviluppatori di Apple che ha ricevuto una risposta ufficiale, la quale conferma il problema:
Risposta Ufficiale:
Ciao aslkdjalksdjasdasd,
Il comportamento è corretto: le informazioni sull’utente vengono inviate nell’ASAuthorizationAppleIDCredential solo durante la registrazione iniziale dell’utente. Gli accessi successivi alla tua app tramite “Accedi con Apple” con lo stesso account non condividono alcuna informazione sull’utente e restituiranno solo un identificativo utente nell’ASAuthorizationAppleIDCredential. Si consiglia di memorizzare in modo sicuro l’ASAuthorizationAppleIDCredential iniziale contenente le informazioni sull’utente fino a quando non sarà possibile verificare che un account sia stato creato correttamente sul tuo server.
Patrick
Come osserva uno sviluppatore:
Quindi aspetta… Se per qualche motivo il primo reindirizzamento da Apple viene perso per una delle moltissime ragioni molto comuni, abbiamo perso permanentemente quell’utente, poiché non esiste alcun altro modo per ottenere le sue informazioni. Non c’è davvero nessun altro modo per ottenere queste informazioni?
e un altro:
Oppure, se qualcosa va storto a valle, avremmo clienti che si lamentano e il supporto tecnico loro direbbe di accedere al sito Apple ID per revocare l’autorizzazione, in modo da poter registrarsi correttamente di nuovo. Credo che questa sarebbe un’esperienza negativa e porterebbe le persone a non utilizzare questo meccanismo di accesso se iniziano ad avere questo tipo di problemi.
Quindi, purtroppo, non penso che si possa utilizzare questo metodo in produzione in modo sicuro. Sarebbe un incubo per il supporto.
Suggerisco di mettere da parte questa funzionalità finché Apple non si renderà conto del problema che ha creato: nel tentativo di migliorare la sicurezza, sembra abbiano compromesso eccessivamente la robustezza.
Che peccato.
Apple ha aggiornato la pagina per sviluppatori “Accedi con Apple” per includere maggiori informazioni sulla raccolta dei dati, la gestione dei dati, ecc.
Ho aperto una pull request per aggiornare il gem omniauth-apple all’ultima versione, che include questo commit e sembra possa risolvere il problema della mancata ricezione dell’email dell’utente ad ogni accesso.
Per provare questa soluzione, ho seguito il post del blog consigliato per configurare le credenziali, ma finora non sono riuscito a capire due cose:
Grazie.
Di solito si invia una PR dopo aver testato con successo qualcosa 
Per favore conferma quando lo avrai fatto.
Sembra una cosa ovvia, ma sarei più incoraggiato se avessimo una dichiarazione da parte di Apple che confermi che ora inviano un’email ogni volta. Cambiare la versione del gem non risolverà il problema se Apple non ha affrontato il problema di base.
Controllerò la mia configurazione quando mi riprogetterò come sviluppatore Apple, cosa che non ho ancora fatto… (questo disastro è stato un po’ scoraggiante, a dirla tutta)
Ho provato a aggiornare la nostra fork del plugin per utilizzare l’ultima versione di omniauth-apple. (Nota che sono necessari alcuni altri cambiamenti, non solo un aggiornamento del numero di versione).
tl;dr: è ancora rotto
Sono riuscito a farlo funzionare con delle modifiche sul mio sandbox, ma presenta ancora diversi problemi:
Apple utilizza una richiesta POST sul callback. Questo non è comune nelle implementazioni OAuth perché significa che i cookie con samesite=Lax non verranno inviati con la richiesta. Ciò significa che Discourse non riesce a leggere i cookie di sessione durante il callback e quindi restituisce un errore CSRF.
Un workaround INSECURO consiste nel disabilitare questa sicurezza impostando i cookie di Discourse su samesite=None.
L’uso di una richiesta POST senza un token CSRF attiva anche un’altra misura di sicurezza nel core.
Un workaround INSECURO consiste nel rimuovere questa riga.
Stavo ricevendo un errore 403 da Apple quando il gem omniauth recuperava i JWK. Sospetto che l’intestazione Accept: non venga impostata correttamente, ma non l’ho ancora verificato.
Un workaround INSECURO è stato quello di hardcodare le chiavi.
Dopo tutto questo, sono finalmente riuscito ad accedere con Apple. Puoi provarlo su https://sandbox.dtaylor.uk (lo lascerò funzionante per qualche giorno, ma per favore non inserire dati sensibili perché è INSECURO).
E poi… le email e i nomi vengono inclusi solo nella prima autenticazione. Puoi provarlo: accedi con Apple, annulla la creazione dell’account e riprova. Il secondo tentativo non includerà i tuoi dettagli.
Quindi, supponendo che Apple non cambi le cose a breve… come potremmo far funzionare tutto questo?
Per (1) e (2) penso che potremmo convertire il POST di Apple in un GET senza compromettere la sicurezza. Quando riceviamo un POST sul callback, renderizziamo un JavaScript che imposta window.location='/auth/apple/callback?code=...&state=...'. Da lì, funzionerebbe esattamente come qualsiasi altro provider. Tuttavia, penso che intercettare il POST richiederebbe alcune modifiche all’API core.
Per (3), penso che potrebbe essere risolto con un po’ di lavoro sul gem omniauth.
Ma siamo comunque bloccati senza nome/email, quindi non sono sicuro che valga la pena risolvere questi altri problemi
Grazie per averci riprovato e per la tua analisi! Forse inviare un incidente di supporto tecnico ad Apple potrebbe chiarire i problemi rimanenti? Dalla mia esperienza, è più probabile che forniscano possibili soluzioni o soluzioni alternative lì piuttosto che nei forum per sviluppatori Apple.
