El inicio de sesión con Facebook cambió mucho en los últimos meses como parte de nuestro esfuerzo por proteger la privacidad de las personas y brindarles mayor control sobre su información. Comprendemos lo desafiante que puede ser estar al día con todas las actualizaciones. Como ayuda para esto, compilamos un resumen de los cambios recientes, junto con las recomendaciones para incorporarlos.
Ten en mente las siguientes fechas límite para garantizar el funcionamiento fluido de tu aplicación o sitio web.
Para proteger los datos de las personas, ahora se requiere que más permisos se sometan al proceso Revisión de aplicaciones. Para ciertos permisos, también se requiere una verificación de la empresa, y un contrato entre la empresa y Facebook. Para la verificación, las empresas pueden presentar formularios de documentación, como facturas de servicios públicos, licencias empresariales, certificados de formación, artículos de incorporación, números de identificación fiscal, etc. Para el contrato, se deben cumplir requisitos de seguridad adicionales y otras disposiciones sobre datos. Puedes obtener más información sobre el proceso de revisión de aplicaciones optimizado en el tema Revisión de aplicaciones.
En la siguiente tabla, se resumen los niveles de revisión necesarios para los permisos de inicio de sesión con Facebook. Vuelve a consultar esta tabla con frecuencia para ver las actualizaciones.
NO se requiere revisión de aplicaciones | Se requiere revisión de aplicaciones | Se requieren revisión de aplicaciones, verificación de la empresa y contrato |
---|---|---|
|
|
|
|
|
|
|
|
|
|
| |
|
| |
|
| |
| ||
|
* Si todavía no se realizó la actualización a la API Graph, se recomienda volver a solicitar estos permisos antes del 1 de agosto. Si ya se aprobaron para el acceso, los permisos continuarán disponibles después de la actualización a la API Graph 3.0. Los cambios en la API Graph 3.0 se detallan en la entrada de blog del 1 de mayo de 2018. Las aplicaciones se pueden actualizar a la API Graph 3.0 hasta el 8 de enero de 2019.
Si la aplicación o el sitio web ya utilizaban los permisos que se muestran en la tabla anterior antes del 1 de mayo de 2018 cuando se lanzó la revisión optimizada, es posible volver a solicitar el acceso hasta el 1 de agosto de 2018 y garantizar la continuación de su uso.
Las empresas que se basan en la plataforma de Facebook para brindar servicios a otras empresas como proveedores de tecnología de terceros también deben firmar otro contrato. El contrato de proveedor de tecnología limita el uso de los datos al único propósito de atender al cliente en nombre del cual se recopilan los datos. Los clientes importantes que utilizan proveedores de tecnología de terceros pueden estar sujetos a la revisión de aplicaciones y tener la obligación de firmar las condiciones complementarias. Los proveedores de tecnología deben identificar su uso comercial como la prestación de servicios a otras empresas en la configuración del Panel de aplicaciones.
Ciertos permisos y funciones, que se muestran en la siguiente tabla, se volvieron obsoletos. Ya no se devolverán los campos anteriormente accesibles a través de estos permisos y las API devolverán valores vacíos.
Permisos de perfil ampliados | Permisos de acciones de usuario | API |
---|---|---|
|
| Etiquetado de amigos |
|
| Todos los amigos en común |
|
| |
|
| |
|
| |
|
| |
| ||
|
Lee la entrada de blog del 4 de abril de 2018 para obtener más información.
El permiso publish_actions
quedó obsoleto el 24 de abril de 2018. Las aplicaciones creadas antes de esta fecha con aprobación previa para solicitar publish_actions
pueden enviar solicitudes de ese tipo hasta el 1 de agosto de 2018. Si se utilizaba publish_actions
, se recomienda pasar a usar los cuadros de diálogo de contenido compartido para web, iOS y Android. (Lee la entrada de blog del 1 de mayo de 2018.)
Desde el 1 de mayo de 2018, ya no se pueden solicitar los siguientes permisos, los cuales se volverán obsoletos desde el 8 de enero de 2019 para aplicaciones y sitios web con aprobación obtenida antes del 1 de mayo de 2018:
timezone
locale
cover
is_verified
updated_time
verified
currency
devices
third_party_id
Consulta la entrada de blog del 1 de mayo de 2018.
La referencia de permisos muestra la lista completa de los permisos disponibles.
Los enlaces a perfiles de usuario creados con ASID ya no funcionan. Es necesario recuperar un enlace de perfil desde el campo user_link
. Estos enlaces no funcionarán si la persona no ha usado la aplicación o el sitio web en 90 días, o si ha rechazado conceder el permiso user_link
a la aplicación. Después de la migración a la API Graph 3.0, este campo solo estará disponible si la aplicación solicita y el usuario aprueba el permiso.
El elemento user_link
solo se resolverá en el perfil de Facebook real del usuario para individuos con sesión iniciada en la red extendida de ese usuario (actualmente se definen como amigos de amigos, pero esto se encuentra sujeto a cambios). Es posible que otros individuos solo puedan enviar una solicitud de amistad o mensaje.
Lee la entrada de blog del 19 de abril de 2018 donde se anuncian estos cambios.
El acceso de la aplicación a los datos del usuario ahora caduca después de 90 días si Facebook no puede verificar la actividad en la aplicación. En algunas plataformas, como los juegos web de Facebook, se puede verificar toda la actividad del usuario. En otras plataformas, como iOS, es posible que los usuarios deban aceptar los permisos en un cuadro de diálogo de inicio de sesión cada 90 días para volver a autorizar el acceso a datos de la aplicación. Lee la entrada de blog del 9 de abril de 2018.
Se recomienda comprobar que la aplicación o el sitio web proporcionen un proceso de reautorización fluido para las personas con tokens de acceso caducados. Obtén más información sobre la actualización de tokens de acceso en Actualización de tokens de acceso del usuario.
Se aclaró la diferencia entre los visitantes que nunca iniciaron sesión y los usuarios con tokens de acceso caducados a fin de que los desarrolladores puedan mostrar la interfaz de usuario correcta para cada situación. Si las aplicaciones utilizan el SDK para JavaScript, FB.getLoginStatus() permite determinar el estado actual de un usuario y obtener un nuevo estado, authorization_expired, para indicar que el token del usuario caducó. Este nuevo estado es distinto del estado not_authorized que se obtiene cuando los usuarios no forman una conexión con la aplicación a través del inicio de sesión con Facebook. Con este nuevo estado expired, se puede recordar al individuo que inició sesión anteriormente con Facebook y solicitarle que vuelva a pasar por el proceso de inicio de sesión para actualizar su cuenta con la información más reciente.
También existe una nueva forma en que los desarrolladores pueden comprobar la caducidad de los tokens en sus aplicaciones y sitios web. En cada usuario de prueba creado para la aplicación, es posible elegir la cantidad de tiempo antes de que caduquen los tokens de acceso. Si se decide usar una fecha de caducidad personalizada, se puede establecer un intervalo de un minuto o mucho más si es necesario para los fines de prueba exclusivos de la aplicación. Esta opción de configuración se encuentra en el menú Editar de cada usuario de prueba y se aplica a todas las aplicaciones o los sitios web que utiliza el usuario de prueba.
Para el SDK para JavaScript, se agregó un nuevo campo al objeto authResponse
llamado reauthorize_required_in
. Gracias a esto, los desarrolladores que trabajan con tokens de corta duración pueden saber la fecha de caducidad de la autorización de 90 días de una persona. Si deseas ampliar proactivamente la sesión de la persona otros 90 días, puedes llamar a login()
con el parámetro auth_type=reauthorize
a fin de solicitar a esa persona que acepte nuevamente los permisos actuales concedidos a la aplicación para poder continuar.
Estas actualizaciones se anunciaron en una entrada de blog del 1 de mayo de 2018.
Existe una nueva opción de configuración Aplica HTTPS para el inicio de sesión con Facebook disponible en el panel de aplicaciones. Cuando se activa esta opción, se requiere el uso de HTTPS en todos los redireccionamientos de inicio de sesión con Facebook, y todas las llamadas al SDK de Facebook para JavaScript que devuelvan o requieran un token de acceso deben realizarse únicamente desde páginas HTTPS. Lee la entrada de blog del 8 de junio de 2018.
El uso de esta configuración ya es un requisito para todas las nuevas aplicaciones creadas desde marzo de 2018. Las aplicaciones y los sitios web existentes tienen hasta el 6 de octubre de 2018 para aceptar esta opción antes de que se habilite automáticamente. Todas las páginas o los URI de redireccionamiento no seguros que realicen llamadas a la API o inicios de sesión con el SDK para JavaScript desde páginas HTTP dejarán de funcionar después de esa fecha.
"Integraciones empresariales" se muestra como una lista de servicios separada de las aplicaciones en la configuración de la cuenta de una persona. Estos son servicios a los que las personas conectaron su cuenta de Facebook y otorgaron permisos especiales para administrar páginas, eventos, anuncios o mensajes de página. El acceso a las API para empresas continuará funcionando como antes de este cambio, sin caducidad, hasta que un usuario de Facebook elimine la integración con la página, la cuenta publicitaria, el evento, etc. Lee la entrada de blog del 1 de mayo de 2018 donde se anuncia este cambio.
Si las personas eliminan la aplicación o el sitio web de la configuración de aplicaciones y sitios web de Facebook, podemos brindarles la opción de solicitar que la aplicación o el sitio web eliminen de Facebook toda la información recibida sobre ellos. La experiencia en Facebook les informará cuándo enviaron una solicitud y cuándo la reconoció el servicio. También les proporcionará un número de confirmación y una forma de comprobar el estado de su solicitud. Al ofrecer esta opción a las personas, es posible automatizar las solicitudes de servicio al cliente, demostrar que su información se maneja con responsabilidad y satisfacer los requisitos de cumplimiento, como los del reglamento RGPD.
Para habilitar esta opción, debes proporcionarnos una URL de devolución de llamada a donde podamos enviar la solicitud. Puedes agregar la URL de devolución de llamada a la página Configuración de inicio de sesión con Facebook en el panel de aplicaciones. La devolución de llamada debe utilizar HTTPS. Consulta la documentación para obtener detalles. Lee la entrada de blog del 25 de mayo de 2018.
Ahora existe una manera de proporcionar la información de contacto del responsable de protección de datos (DPO) a los usuarios europeos. Ve a la página Configuración de inicio de sesión con Facebook en el panel de aplicaciones para agregar el nombre (opcional), la dirección postal y la dirección de correo electrónico del DPO. Esta información estará disponible en la configuración de las aplicaciones y los sitios web de las personas para que puedan ponerse en contacto con el DPO si tienen preguntas sobre cómo se procesan y se utilizan sus datos. Lee la entrada de blog del 25 de mayo de 2018.
Para las aplicaciones en modo de desarrollo, las llamadas a la API devolverán datos de usuario solo si la persona tiene un rol en la aplicación (por ejemplo, administrador, desarrollador o evaluador). Esto se aplica a API de perfil de Facebook, de páginas y de otro tipo. Lee la entrada de blog del 24 de abril de 2018.
Las aplicaciones en modo de desarrollo ahora se limitan en frecuencia a 200 llamadas por hora, por par página-aplicación, y solo los usuarios con un rol en la aplicación (administrador, desarrollador o evaluador) pueden obtener acceso. Consulta los gráficos sobre la actividad de limitación de frecuencia de tu aplicación en el panel de aplicaciones. Los desarrolladores y los administradores de aplicaciones en el modo público solo pueden acceder a los permisos que se aprobaron para la aplicación.
Es conveniente que los desarrolladores tengan estas limitaciones en cuenta al desarrollar nuevas funciones para sus aplicaciones.