@David, el autor del PR ha respondido a mi comentario, ¿qué opinas tú sobre esto?:
Yo:
¿Este PR parece resolver el problema de la falta de nombre y correo electrónico?
Autor del PR:
No, por desgracia no. Apple debe proporcionar un punto final de API REST para recuperar el nombre y el correo electrónico, ya que actualmente solo pasan esta información una vez tras una autenticación exitosa y no en autenticaciones posteriores.
¿No es suficiente con que sea una sola vez en la autorización inicial para nosotros?
Es mejor que nada, pero aún no es bueno. Por ejemplo, si “inicias sesión con Apple”, pero luego haces clic en cancelar en la pantalla de “crear cuenta”. O si conectas una cuenta existente con Apple y luego decides crear una nueva cuenta en su lugar. Esperemos que Apple resuelva eso antes de que termine la versión beta
¿Existe una implementación funcional de la función de inicio de sesión con Apple en esta etapa? Un sitio para el que estoy trabajando en un marketplace planea tener una aplicación para iOS; sin embargo, sin esta opción, no podemos habilitar otras opciones de autenticación a menos que queramos que nuestra aplicación sea rechazada por violar las directrices de la tienda de aplicaciones.
Siéntete libre de instalar el plugin para probarlo, pero no tengo conocimiento de que ya esté resuelto. Sin embargo, no recomendaría usarlo en producción hasta que esté finalizado o, al menos, aprobado por un desarrollador que tenga tiempo para confirmar los detalles.
Soy un gran defensor de esta función. Me encantaría verla integrada en Discourse vanilla, al igual que las otras opciones de inicio de sesión.
Creo que no se puede recuperar ese tipo de información a propósito.
Mostrar un botón de “Iniciar sesión con Apple” en tu aplicación o sitio web significa que las personas pueden iniciar sesión o registrarse con solo un toque usando su ID de Apple, evitando rellenar formularios, verificar direcciones de correo electrónico y elegir contraseñas. Iniciar sesión con Apple ofrece una forma nueva y más privada de entrar de manera sencilla y rápida en aplicaciones y sitios web, brindando a las personas una experiencia de inicio de sesión coherente en la que pueden confiar y la comodidad de no tener que recordar múltiples cuentas y contraseñas. En los casos en que decidas solicitar un nombre y una dirección de correo electrónico, las personas tienen la opción de mantener su correo electrónico privado y compartir en su lugar una dirección de correo electrónico única y aleatoria.
Tienes razón, la privacidad es una de las partes clave de «Iniciar sesión con Apple», pero lo esencial de tu cita es:
Asumiendo que las personas eligen darnos su nombre y correo electrónico, esperaríamos recibirlos del proveedor cada vez que el usuario inicie sesión. En la implementación actual, esto no ocurre. Tras la primera autenticación, no recibimos información del usuario.
No creo que esto sea algo que el autor de la gem pueda solucionar; es algo que Apple tendría que cambiar. No veo que eso ocurra pronto, así que quizás solo tengamos que pedir a los usuarios que introduzcan su nombre y correo electrónico en Discourse manualmente
Logré hacer que funcione parcialmente un fork del plugin de Robert/merefield (el fork solo implica cambiar a una copia del gem omniauth que compilé a partir de la última fuente en GitHub). Sin embargo, en mi Discourse de prueba (que tiene HTTPS de extremo a extremo mediante ngrok), tuve que establecer la configuración del sitio “Cookies del sitio” en (ninguna) para que la autenticación funcionara. Con la configuración desactivada, puedo crear una cuenta (incluso si cerré el formulario de registro) y volver a iniciar sesión; sin embargo, no puedo hacerlo si la configuración está activada.
A continuación se muestra el rastreo de la pila (backtrace) de un intento de inicio de sesión fallido:
¿Alguien aquí tiene alguna sugerencia sobre si o cómo puedo reescribir el plugin para que ya no requiera desactivar esta configuración del sitio para que sus funciones principales funcionen? Mi código del plugin se encuentra en https://github.com/sau226dev/discourse-sign-in-with-apple y el último código que utilicé para reconstruir el gem omniauth debería estar en la misma organización de GitHub.
Gracias por cualquier ayuda que puedan brindar de antemano,
El plugin funcionaba en cierta medida originalmente, pero no ha recibido atención recientemente debido al problema descrito por David arriba.
Hasta que recibamos noticias positivas de que Apple ha resuelto ese bloqueo fundamental (enviar nombre y correo electrónico en cada intento de inicio de sesión), no vale la pena mantener este código, en mi opinión. No creo que haya nada que puedas hacer para sortearlo. Por eso ni siquiera he intentado actualizar las dependencias. El plugin fallaría en las pruebas de todos modos.
Así que este no es un plugin ‘lanzado’ (de lo contrario, este o un tema similar estaría en #plugin) y es poco probable que reciba soporte hasta que eso ocurra. Estaría encantado de ‘terminarlo’ si ese problema se resolviera y Apple proporcionara esa información.
Por cierto, hay otro problema importante: para usarlo en tu propio sitio, necesitas pagar por el Programa de Desarrolladores de Apple para obtener acceso a la configuración en los sistemas de Apple. Esto, sospecho, disuadirá a muchos sitios con presupuesto limitado, ya que no es un registro gratuito o de bajo costo.
@orenwolf Esto (la falta de correo electrónico/nombre devuelto en los siguientes inicios de sesión) no pareció ser un problema. Creo que pude cerrar la ventana de registro y reanudar el proceso con los datos correctos. Como mencioné antes, pude iniciar sesión con Apple inmediatamente después sin ningún problema.
El único problema que enfrenté fue el error CSRF, a menos que se desactivara la configuración del sitio que mencioné anteriormente. Un problema potencial es la falta de un campo para el nombre en el formulario de inicio de sesión y que el nombre de usuario sea lo que aparece antes del símbolo @ en el correo electrónico (sin embargo, si me preguntas, estos problemas potenciales o no son un problema o pueden ser solucionados fácilmente por el usuario).
Además de los comentarios de David anteriores, encontré un tema relacionado en el sitio de soporte para desarrolladores de Apple que recibió una respuesta oficial que confirma el problema:
Respuesta oficial:
Hola aslkdjalksdjasdasd,
Este comportamiento es correcto; la información del usuario solo se envía en el ASAuthorizationAppleIDCredential durante el registro inicial del usuario. Los siguientes inicios de sesión en tu aplicación mediante “Iniciar sesión con Apple” con la misma cuenta no comparten información del usuario y solo devolverán un identificador de usuario en el ASAuthorizationAppleIDCredential. Se recomienda almacenar de forma segura el ASAuthorizationAppleIDCredential inicial que contiene la información del usuario hasta que puedas validar que se ha creado una cuenta correctamente en tu servidor.
Patrick
Como comenta un desarrollador:
Entonces, espera… si por alguna razón la primera redirección desde Apple se pierde por una de las muchas razones muy comunes, habremos perdido permanentemente a ese usuario, ya que no hay otra forma de obtener su información. ¿No existe ninguna otra manera de obtener esta información?
y otro:
O si algo sale mal aguas abajo, tendríamos a clientes quejándose y el soporte les diría que vayan al sitio web de AppleID para revocar el permiso, para que puedan registrarse correctamente nuevamente. Creo que esto será una mala experiencia y hará que la gente no use este mecanismo de inicio de sesión si empiezan a tener este tipo de problemas.
Por lo tanto, no creo que sea seguro utilizar esto en producción, lamentablemente. Esto sería una pesadilla para el soporte.
Sugiero que dejemos esto en espera hasta que Apple se dé cuenta del problema que han creado: en su intento de mejorar la seguridad, parece que han comprometido excesivamente la robustez.
Apple ha actualizado su página para desarrolladores de “Iniciar sesión con Apple” para incluir más información sobre la recopilación de datos, la gestión de datos, etc.
He abierto una solicitud de extracción para actualizar la gema omniauth-apple a la versión más reciente, la cual incluye este commit que parece poder resolver el problema de no recibir el correo electrónico del usuario en cada inicio de sesión.
Para probarlo, seguí la publicación recomendada en el blog para configurar las credenciales, pero hay dos cosas que aún no he logrado averiguar:
¿Cuál es la ruta de la redirección de la URL de retorno necesaria para configurar el ID de servicio con Apple?
¿Cómo obtengo el “archivo de verificación txt”, o acaso no es necesario? Al buscar, encontré menciones de que este se podía descargar desde Apple como parte de la configuración de comunicación de dominio/correo electrónico, pero parece que ya no es así:
Normalmente, se envía una PR después de haber probado algo con éxito
Por favor, confirma cuando lo hayas hecho.
Aunque parece algo obvio, estaría más animado si tuviéramos una declaración de Apple confirmando que ahora envían un correo electrónico cada vez. Cambiar la versión del gem no resolverá eso si Apple no ha abordado el problema central.
Revisaré mi configuración cuando vuelva a suscribirme como Desarrollador de Apple, algo que aún no he hecho… (este asunto fue un poco desalentador, la verdad)
He intentado actualizar nuestro fork del plugin para usar la última versión de omniauth-apple. (Tenga en cuenta que se requieren algunos otros cambios, no solo actualizar el número de versión).
tl;dr: sigue sin funcionar
Logré hacerlo funcionar con un parche en mi entorno de pruebas, pero aún presenta varios problemas:
Apple utiliza una solicitud POST en la devolución de llamada. Esto no es común en las implementaciones de OAuth porque significa que las cookies con samesite=Lax no se enviarán con la solicitud. Esto implica que Discourse no puede leer las cookies de sesión durante la devolución de llamada y, por lo tanto, lanza un error CSRF.
La solución INSEGURO es desactivar esta medida de seguridad cambiando las cookies de Discourse a samesite=None.
El uso de una solicitud POST sin un token CSRF también activa otra medida de seguridad en el núcleo.
Recibía un error 403 de Apple cuando la gem de omniauth obtenía los JWKs. Sospecho que el encabezado Accept: no se está configurando correctamente, pero aún no lo he verificado.
La solución INSEGURO fue codificar las claves de forma manual.
Después de todo eso, finalmente pude iniciar sesión con Apple. Puede probarlo en https://sandbox.dtaylor.uk (lo dejaré funcionando durante unos días, pero por favor no introduzca información sensible allí, ya que es INSEGURO).
Y luego… los correos electrónicos y nombres solo se incluyen en la primera autenticación. Puede probarlo: inicie sesión con Apple, cancele la creación de la cuenta y luego intente nuevamente. El segundo intento no incluirá sus datos.
Así que, suponiendo que Apple no vaya a cambiar nada pronto… ¿cómo podríamos hacer que esto funcione?
Para (1) y (2), creo que podríamos convertir la solicitud POST de Apple en una GET sin comprometer la seguridad. Cuando recibimos una POST en la devolución de llamada, renderizamos un script de JavaScript que establece window.location='/auth/apple/callback?code=...&state=...'. A partir de ahí, funcionaría exactamente como cualquier otro proveedor. Sin embargo, creo que interceptar la POST requeriría algunos cambios en la API central.
Para (3), creo que probablemente se podría solucionar con un poco de trabajo en la gem de omniauth.
Pero seguimos atascados sin obtener el nombre y el correo electrónico, así que no estoy seguro de si vale la pena solucionar estos otros problemas
¡Gracias por intentarlo de nuevo y por tu análisis! ¿Quizás presentar un incidente de soporte técnico a Apple podría arrojar luz sobre los problemas pendientes? Por mi experiencia, es más probable que allí te proporcionen posibles soluciones o alternativas que en los foros de desarrolladores de Apple.
