El inicio de sesión con Facebook ha cambiado mucho en los últimos meses, ya que estamos trabajando para proteger la privacidad de los usuarios y proporcionarles un mayor control sobre su información. Somos conscientes de que puede ser difícil mantenerse al día de todas las actualizaciones. Para ayudarte, hemos elaborado un resumen de los cambios recientes, junto con recomendaciones para incorporarlos.
Ten en cuenta los siguientes plazos a fin de garantizar un funcionamiento correcto de tu aplicación o sitio web.
A fin de proteger los datos de los usuarios, ahora exigimos que un mayor número de permisos se sometan al proceso de revisión de la aplicación. Para determinados permisos, también exigimos la verificación del negocio y un contrato entre el negocio y Facebook. Para verificar los negocios, se pueden proporcionar distintos tipos de documentación, como facturas, licencias del negocio, certificados de formación, artículos de incorporación, números de identificación fiscal, etc. El contrato presenta requisitos de seguridad adicionales y otras disposiciones relativas a los datos. Para obtener más información sobre la mejora del proceso de revisión de la aplicación, consulta el tema Revisión de la aplicación.
En la tabla siguiente se resume el nivel de revisión necesario para los permisos del inicio de sesión con Facebook. Comprueba de vez en cuando si hay actualizaciones en esta tabla.
Revisión de la aplicación NO obligatoria | Revisión de la aplicación obligatoria | Revisión de la aplicación, verificación del negocio y contrato obligatorios |
---|---|---|
|
|
|
|
|
|
|
|
|
|
| |
|
| |
|
| |
| ||
|
* Si aún no has realizado la actualización a la API Graph, te recomendamos que vuelvas a solicitar estos permisos antes del 1 de agosto. Si se te aprueba el acceso, seguirán a tu disposición una vez actualices a la versión 3.0 de la API Graph. Los cambios en la versión 3.0 de la API Graph se detallan en estapublicación en el blog del 1 de mayo de 2018. Las aplicaciones pueden actualizarse a la versión 3.0 de la API Graph hasta el 8 de enero de 2019.
Si tu aplicación o sitio web ya usaba los permisos que se muestran en la tabla antes del 1 de mayo de 2018, cuando empezamos a implementar la mejora de la revisión, tienes hasta el 1 de agosto de 2018 para volver a solicitar acceso y asegurarte de que puedes continuar usándolos después de esa fecha.
Las empresas que emplean la plataforma de Facebook para proporcionar servicios a otras empresas como proveedores tecnológicos de terceros también deben firmar un contrato adicional. El contrato de proveedores tecnológicos restringe el uso de los datos con la única finalidad de proporcionar servicios al cliente en cuyo nombre se recopilan los datos. Los clientes de grandes empresas que usan proveedores tecnológicos de terceros pueden estar sujetos a la revisión de la aplicación y se les puede exigir que firmen los términos adicionales. Los proveedores tecnológicos deben identificar el uso de su negocio como proveedor de servicios para otros negocios en la configuración del panel de aplicaciones.
Hemos retirado algunos permisos y funciones, tal y como se muestra en la siguiente tabla. Los campos que anteriormente eran accesibles a través de estos permisos ya no se devolverán y las API devolverán valores vacíos.
Permisos ampliados del perfil | Permisos de acciones del usuario | API |
---|---|---|
|
| Etiquetado de amigos |
|
| Todos los amigos en común |
|
| |
|
| |
|
| |
|
| |
| ||
|
Lee la publicación en el blog del 4 de abril de 2018 para obtener más información.
El permiso publish_actions
se retiró el 24 de abril de 2018. Las aplicaciones creadas antes de esta fecha que recibieron anteriormente la aprobación para solicitar publish_actions
pueden continuar haciéndolo hasta el 1 de agosto de 2018. Si usabas publish_actions
, te recomendamos que empieces a usar los cuadros de diálogo de contenido compartidos de Facebook para la web, iOS y Android. (Lee la publicación en el blog del 1 de mayo de 2018).
Los siguientes permisos ya no se pueden solicitar desde el 1 de mayo de 2018 y se retirarán a partir del 8 de enero de 2019 para las aplicaciones y los sitios web que fueron aprobados antes del 1 de mayo de 2018.
timezone
locale
cover
is_verified
updated_time
verified
currency
devices
third_party_id
(Consulta la publicación en el blog del 1 de mayo de 2018).
Puedes ver la lista completa de permisos en la referencia de permisos.
Los enlaces a los perfiles del usuario creados mediante ASID ya no funcionan. Para recuperar un enlace del perfil, debes usar el campo user_link
. Estos enlaces no funcionarán si el usuario no ha usado tu aplicación o sitio web en un período de 90 días o si no ha otorgado el permiso user_link
a tu aplicación. Después de migrar a la versión 3.0 de la API Graph, este campo solo estará disponible si tu aplicación solicita el permiso y el usuario lo aprueba.
El campo user_link
solo se resolverá en el perfil de Facebook real del usuario para las personas que tengan la sesión iniciada en la red ampliada de dicho usuario (que actualmente se define como amigos de amigos, pero puede ser objeto de cambios). Es posible que el resto de personas solo tengan la oportunidad de enviar una solicitud de amistad o de mensaje.
Lee la publicación en el blog del 19 de abril de 2018 en la que se presentan dichos cambios.
El acceso de tu aplicación a los datos de los usuarios ahora expira tras 90 días, a no ser que Facebook pueda verificar actividad en tu aplicación. En algunas plataformas, como los juegos web de Facebook, se puede verificar toda la actividad de los usuarios, pero en otras aplicaciones, como iOS, es posible que los usuarios tengan que volver a autorizar el acceso a los datos de tu aplicación mediante la aceptación de permisos en un cuadro de diálogo de inicio de sesión cada 90 días. Lee la publicación en el blog del 9 de abril de 2018.
Te recomendamos que te asegures de que tus aplicaciones y sitios web ofrecen un flujo de reautorización óptimo para los usuarios cuyos identificadores de acceso han caducado. Para obtener más información sobre la actualización de los identificadores de acceso, consulta Actualización de los identificadores de acceso de los usuarios.
Hemos aclarado la diferencia entre los visitantes que nunca han iniciado sesión y los usuarios que tienen identificadores de acceso caducados a fin de que los desarrolladores puedan mostrar la interfaz de usuario más adecuada para cada situación. En el caso de las aplicaciones que usan el SDK para JavaScript, FB.getLoginStatus() te permite determinar el estado en que se encuentra un usuario y, además, ahora devuelve un estado nuevo, authorization_expired, que indica que ha caducado el identificador de un usuario. Este nuevo estado es distinto del estado not_authorized que obtendrás para los usuarios que no han establecido ninguna conexión con tu aplicación mediante el inicio de sesión con Facebook. Para este nuevo estado caducado, es posible que quieras recordar a la persona que anteriormente ya ha iniciado sesión con Facebook y solicitarle que vuelva a realizar el flujo de inicio de sesión para actualizar la cuenta con su información más reciente.
Asimismo, proporcionamos un nuevo método a los desarrolladores para que prueben la caducidad de los identificadores en sus aplicaciones y sitios web. Para cada usuario de prueba de tu aplicación, podrás elegir el período de tiempo antes de que caduquen los identificadores de acceso. Si eliges usar un tiempo de caducidad personalizado, puedes establecer el intervalo para que dure únicamente un minuto o mucho más si es necesario para las finalidades exclusivas de prueba de tu aplicación. Puedes encontrar esta configuración en el menú Editar de cada usuario de prueba, que se aplica a todas las aplicaciones o sitios web que use el usuario de prueba.
En el caso del SDK para JavaScript, estamos añadiendo un nuevo campo en el objeto authResponse
denominado reauthorize_required_in
. Este ofrece a los desarrolladores que trabajan con identificadores de corta duración la capacidad de saber cuándo caducará la autorización de la aplicación de 90 días de un usuario. Si quieres ampliar de forma proactiva la sesión del usuario en otros 90 días, puedes llamar a login()
con el parámetro auth_type=reauthorize
, que le pedirá que vuelva a aceptar los permisos otorgados actualmente a tu aplicación para poder continuar.
Estas actualizaciones se anunciaron en una publicación en el blog el 1 de mayo de 2018.
Ahora hay disponible una nueva configuración denominada Aplicar HTTPS para el inicio de sesión con Facebook en el panel de aplicaciones. Cuando se activa, esta requiere que todas las redirecciones del inicio de sesión con Facebook usen HTTPS, y que todas las llamadas al SDK de Facebook para JavaScript que devuelven o requieren un identificador de acceso se produzcan únicamente en páginas HTTPS. Lee la publicación en el blog del 8 de junio de 2018.
Ya se ha requerido que todas las aplicaciones nuevas creadas desde marzo de 2018 usen esta configuración, y las aplicaciones y los sitios web existentes que usan el inicio de sesión con Facebook tienen hasta el 6 de octubre de 2018 para activarla antes de que se active automáticamente. Todos los URI y las páginas de redirección poco seguros que realicen llamadas a la API o al inicio de sesión con el SDK para JavaScript de páginas HTTP dejarán de funcionar después de dicha fecha.
La opción "Integraciones del negocio" se muestra como una lista distinta de los servicios y separada de las aplicaciones en la configuración de la cuenta de un usuario. Esta corresponde a los servicios que las personas conectaron a su cuenta de Facebook y a los que otorgaron permisos especiales para administrar páginas, eventos, anuncios o mensajes de la página. Tu acceso a las API para empresas continuará funcionando igual que antes de este cambio, sin caducidad, hasta que un usuario de Facebook elimine la integración a la página, la cuenta publicitaria, el evento, etc. Lee la publicación en el blog del 1 de mayo de 2018 en la que se presenta dicho cambio.
Si los usuarios quitan tu aplicación o sitio web de la configuración de aplicaciones o sitios web, podemos proporcionarles la opción de solicitar que tu aplicación o sitio web elimine de Facebook toda la información que recibiste acerca de ellos. La experiencia de Facebook informará a los usuarios de cuándo enviaron una solicitud y de cuándo la confirmó tu servicio. También les proporcionará un número de confirmación que subministras y una forma de comprobar el estado de su solicitud. Ofrecer esta opción a los usuarios puede ayudar a automatizar las solicitudes de servicio de los clientes, demostrar que administras su información de forma responsable y satisfacer los requisitos de cumplimiento, como el RGPD.
Para habilitar esta opción, necesitamos que nos proporciones una URL de devolución de llamada en la que podamos enviar la solicitud. Puedes añadir la URL de devolución de llamada a la página de configuración de inicio de sesión con Facebook de tu aplicación en el panel de aplicaciones. Tu devolución de llamada debe usar el protocolo HTTPS. Consulta la documentación para obtener detalles. Lee la publicación en el blog del 25 de mayo de 2018.
Ahora, ofrecemos una forma de proporcionar fácilmente la información de contacto del delegado de protección de datos (DPO) a los usuarios europeos. Ve a la página de configuración del inicio de sesión con Facebook de tu aplicación en el panel de aplicaciones para añadir el nombre del DPO (opcional), la dirección postal y la dirección de correo electrónico. Esta información estará disponible en la configuración de las aplicaciones y los sitios web de los usuarios a fin de que puedan ponerse en contacto con tu DPO si tienen preguntas sobre cómo se procesan o se usan sus datos. Lee la publicación en el blog del 25 de mayo de 2018.
Para las aplicaciones que están en modo de desarrollo, las llamadas a la API solo devolverán datos de aquellos usuarios que tienen un rol en la aplicación (p. ej., el administrador, el desarrollador o el evaluador). Esto se aplica al perfil, las páginas y otras API de Facebook. Lee la publicación en el blog del 24 de abril de 2018.
Ahora, las aplicaciones que están en modo de desarrollo tienen una limitación de frecuencia de 200 llamadas por hora, por par de página y aplicación, y solo pueden acceder a los usuarios que tienen un rol en la aplicación (administrador, desarrollador o evaluador). Consulta los gráficos de la actividad de limitación de frecuencia de tu aplicación en el panel de aplicaciones. Los desarrolladores y administradores de aplicaciones del modo público solo pueden acceder a los permisos para los que se aprobó la aplicación.
Recomendamos que los desarrolladores tengan en cuenta estas limitaciones cuando desarrollen nuevas funciones para sus aplicaciones.