Los problemas 1 y 2 son causados por una decisión deliberada de implementación de Apple. Por lo tanto, no se trata realmente de un incidente técnico y podemos encontrar soluciones alternativas. El problema 3 está relacionado con la gema omniauth-apple, por lo que podemos solucionarlo.
Lo que necesitamos de Apple es que incluyan el nombre y el correo electrónico en los flujos de autenticación posteriores. Lamentablemente, han reconocido este comportamiento y han indicado que funciona según lo diseñado: https://forums.developer.apple.com/thread/121496
Este comportamiento es correcto: la información del usuario solo se envía en ASAuthorizationAppleIDCredential durante el registro inicial del usuario. Los inicios de sesión posteriores en tu aplicación mediante «Iniciar sesión con Apple» con la misma cuenta no comparten ninguna información del usuario y solo devolverán un identificador de usuario en ASAuthorizationAppleIDCredential. Se recomienda almacenar de forma segura la instancia inicial de ASAuthorizationAppleIDCredential que contiene la información del usuario hasta que puedas validar que se ha creado correctamente una cuenta en tu servidor.
Sin embargo, me pregunto: ¿alguien ha visto otros sitios web que utilicen «Iniciar sesión con Apple»? Creo que solo he visto aplicaciones nativas que lo usan
Esta función tiene mucho sentido para mí, ya que nuestra aplicación iOS se vincula a nuestra web de Discourse y la aplicación no requiere inicio de sesión para otras funciones.
Es muy conveniente para los usuarios iniciar sesión con este método, ya que la mayoría ya tienen sesión iniciada en el dispositivo y Apple Pay, utilizado para compras dentro de la aplicación, usa la misma cuenta.
En mi opinión, aún tendría sentido contactar a DTS de Apple para ver qué sugieren como solución alternativa y también para darles la retroalimentación de que esto está causando problemas. (Desafortunadamente, no tengo suficiente conocimiento sobre este tema para tener esa conversación con ellos.)
Está lejos de ser tan omnipresente como Google/FB/etc., pero lo he visto en algunos lugares, por ejemplo, ebay.com, wordpress.com y kayak.com.
Sin embargo, es posible que utilicen una API diferente. Existe un script de JS que puedes agregar, pero creo que no se integrará con el sistema OAuth más genérico de Discourse:
Sospecho que Kayak y WordPress están almacenando en caché la información del usuario del primer intento de autenticación, siguiendo la recomendación de Apple.
Supongo que probablemente tendremos que adoptar este enfoque, pero no es particularmente robusto (por ejemplo, si la conexión de red se interrumpe durante el primer intento, o si Discourse se restaura desde una copia de seguridad, o si el usuario cambia su dirección de correo electrónico de Apple). Y, en mi opinión, es ligeramente peor desde el punto de vista de la privacidad (¡tenemos que almacenar correos electrónicos de usuarios que aún ni siquiera se han registrado!).
Creo que lo han pulido un poco, pero no puedo encontrar fácilmente cambios específicos.
¿Crees que recibir un correo electrónico solo una vez no es un gran problema? Supongo que necesitamos probar qué sucede cuando cambias tu correo electrónico en el correo electrónico de tu Apple ID.
Deberíamos seguir recibiendo el mismo UID, pero no recibiremos el nuevo correo electrónico. El usuario tendrá que actualizarlo manualmente en Discourse.
Supongo que deberíamos verificar esto dos veces, pero honestamente no lo veo como un gran drama que nos impida implementar esto.
El flujo de inicio de sesión en dispositivos i es simplemente increíble con el inicio de sesión de Apple, además obtienes autenticación en dos pasos con Face ID.
Leí este tema 2-3 veces, pero no recuerdo si ustedes intentaron obtener el correo electrónico del token JWT proporcionado.
Así es como lo hago en código nativo. No estoy seguro de si la API web lo permite.
En el primer inicio de sesión, puedes obtener el correo electrónico directamente desde ASAuthorizationAppleIDCredential.email.
En los inicios de sesión posteriores, el correo electrónico se puede encontrar si decodificas los datos del JWT y obtienes el campo “email”.
Con esto, ¿se puede implementar la funcionalidad?
El correo electrónico proporcionado será el elegido por el usuario, personal o aleatorio.
Es muy extraño, porque en la versión nativa logré que funcionara simplemente usando la propiedad de correo electrónico del JWT.
Si no lo actualizan en la web para que sea similar, la única solución podría ser generar automáticamente un correo electrónico ficticio (confirmado automáticamente) y permitir que el usuario lo cambie después si lo desea.
Esto implicaría confiar en el ID que proporciona Apple, lo cual no es una mala solución, pero huele un poco a solución rápida .
Sabemos que podemos hacer que esto funcione. Lo que se complica es:
Tu correo electrónico de Apple ID es jane.champion@somewhere.com
Te registras en Discourse con Apple
Cambias tu correo electrónico de Apple ID a jane.row@somewhere.com
Inicias sesión en Discourse… aún creemos que eres jane.champion@somewhere.com
Tus notificaciones por correo electrónico en Discourse rebotarán para siempre.
No tenemos claro qué proceso está establecido cuando los correos electrónicos de Apple ID cambian y cómo podemos reaccionar a ello, si es que podemos hacerlo.
Mi postura al respecto es que… simplemente convivimos con este caso excepcional y, al menos, los usuarios pueden optar por cambiar sus correos electrónicos en Discourse para casos como este.
He estado probando hoy y, la buena noticia es que parece que Apple lo ha solucionado Veo la dirección de correo electrónico presente en cada autenticación.
Aún tengo algunos problemas que resolver, pero espero tener algo público esta semana.
Diría que este es sin duda un candidato para incluirse con Discourse. Deberíamos aspirar a integrar el código en el núcleo o, al menos, empaquetar el plugin para la próxima versión principal (certainly not the one next week though ).
Sí, podemos moverlo del plugin al núcleo más adelante con un esfuerzo mínimo. Un problema es que es mega-difícil de configurar en comparación con Google, Facebook, etc.
Necesitas una cuenta de desarrollador de Apple (¿de pago?) y debes configurar toda clase de verificaciones de dominio y certificados. Con un buen howto, definitivamente es alcanzable.
Lo agregaré a mi lista para actualizar el plugin y poder probarlo. Si funciona bien, podemos pasarlo al núcleo bastante fácilmente.
Veo la dirección de correo electrónico presente en cada autenticación.