I problemi 1 e 2 sono causati da una scelta deliberata di implementazione da parte di Apple. Quindi non si tratta realmente di un incidente tecnico e possiamo trovare una soluzione alternativa. Il problema 3 riguarda il gem omniauth-apple, quindi possiamo risolverlo.
Ciò di cui abbiamo bisogno da Apple è includere nome ed e-mail nei flussi di autenticazione successivi. Purtroppo hanno riconosciuto il comportamento, affermando che funziona come previsto: https://forums.developer.apple.com/thread/121496
Questo si comporta correttamente: le informazioni sull’utente vengono inviate solo in ASAuthorizationAppleIDCredential durante la prima registrazione 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 identificatore utente in ASAuthorizationAppleIDCredential. Si consiglia di memorizzare in modo sicuro l’ASAuthorizationAppleIDCredential iniziale contenente le informazioni sull’utente fino a quando non si può verificare che un account sia stato creato con successo sul tuo server.
Tuttavia, sono curioso: qualcuno ha visto altri siti web che utilizzano “Accedi con Apple”? Credo di aver visto solo app native che lo utilizzano
Questa funzione ha molto senso per me: la nostra app iOS si collega al nostro sito web Discourse e l’app non richiede alcun login per le altre funzionalità.
È molto comodo per gli utenti accedere con questo metodo, poiché la maggior parte è già connessa sul dispositivo e Apple Pay, utilizzato per gli acquisti in-app, utilizza lo stesso account.
A mio parere avrebbe comunque senso contattare l’assistenza DTS di Apple per vedere quale soluzione alternativa suggeriscono e per fornire loro il feedback che questa situazione sta causando problemi. (Purtroppo non ho conoscenze sufficienti sull’argomento per avere questa conversazione direttamente con loro.)
Non è affatto diffuso quanto Google/FB/altre, ma l’ho visto in alcuni casi, ad esempio su ebay.com, wordpress.com e kayak.com.
Tuttavia, potrebbero utilizzare un’API diversa. Esiste uno script JS che puoi aggiungere, ma che, a quanto pare, non si integrerà con il sistema OAuth più generico di Discourse:
Stanno usando la libreria JavaScript di Apple, sì. Ma dietro le quinte utilizza comunque la stessa API ‘OAuth’ (ma non davvero OAuth).
Ebay non sta nemmeno cercando di recuperare le informazioni dell’utente. Dopo aver effettuato l’accesso con Apple, ti viene chiesto di inserire la tua email:
Sospetto che Kayak e Wordpress stiano memorizzando nella cache le informazioni dell’utente dal primo tentativo di autenticazione, come consigliato da Apple.
Immagino che questa sia probabilmente l’approccio che dovremo adottare, ma non è particolarmente robusto (ad esempio, se la connessione di rete viene interrotta durante il primo tentativo, o se Discourse viene ripristinato da un backup, o se l’utente cambia il proprio indirizzo email Apple). E, a mio avviso, è leggermente peggiore dal punto di vista della privacy (dobbiamo memorizzare le email per utenti che non si sono nemmeno ancora registrati!)
Recentemente è cambiato qualcosa riguardo all’accesso con Apple?
Possiamo certamente farlo funzionare così com’è: richiederà qualche giorno per lavorare intorno a questi problemi. Tuttavia, saremo comunque limitati a ricevere solo l’email e il nome al primo accesso.
lo aggiungerò alla mia lista per portare il plugin allo stato necessario, così da poterlo testare. Se funziona correttamente, possiamo integrarlo nel core con relativa facilità.
Ho letto questo argomento 2-3 volte, ma non ricordo se voi avete provato a estrarre l’email dal token JWT fornito.
Questo è come lo faccio io nel codice nativo. Non sono sicuro che la web API lo consenta.
Al primo accesso, puoi ottenere l’email direttamente da ASAuthorizationAppleIDCredential.email.
Per gli accessi successivi, l’email può essere trovata se decodifichi i dati JWT e recuperi il campo “email”.
Con questo, la funzionalità può essere implementata, giusto?
L’email fornita sarà quella scelta dall’utente, personale o casuale.
È strano, perché su nativo è funzionante usando solo la proprietà email del JWT.
Se non aggiornano la versione web per renderla simile, l’unica soluzione potrebbe essere generare automaticamente un’email fittizia (già confermata) e permettere all’utente di modificarla in seguito, se lo desidera.
Questo significherebbe affidarsi all’ID fornito da Apple, che non è una soluzione così male, ma lascia un po’ di cattivo odore .
Sappiamo che possiamo far funzionare questa soluzione. Ciò che si complica è:
L’email del tuo Apple ID è jane.champion@somewhere.com
Ti iscrivi a Discourse con Apple
Modifichi l’email del tuo Apple ID in jane.row@somewhere.com
Accedi a Discourse… pensiamo ancora che tu sia jane.champion@somewhere.com
Le tue notifiche email su Discourse rimbalzeranno per sempre.
Non è chiaro quale processo sia in atto quando le email degli Apple ID cambiano e come possiamo reagire, se possibile.
La mia decisione al riguardo è… che ci dobbiamo semplicemente rassegnare a questo caso limite e, almeno, gli utenti possono scegliere di cambiare le email su Discourse per casi limite come questo.
Direi che questo è certamente un candidato per essere incluso in Discourse. Dovremmo puntare a integrare il codice nel core o almeno a includere il plugin nel prossimo rilascio maggiore (certamente non quello della prossima settimana, però :)).
Sì, possiamo spostarlo da plugin a core in un secondo momento con un minimo sforzo. Un problema è che è estremamente difficile da configurare rispetto a Google/Facebook/ecc.
È necessario un account sviluppatore Apple (a pagamento?) e bisogna configurare tutti i tipi di verifica del dominio e certificati. È certamente fattibile con una buona guida howto.
lo aggiungerò alla mia lista per portare il plugin allo stato necessario, così da poterlo testare. Se funziona correttamente, possiamo integrarlo nel core con relativa facilità.
Vedo l’indirizzo email presente in ogni autenticazione.