Solicitud y revocación de permisos

Cada tipo de proceso de inicio de sesión tiene su propio método de solicitud de permisos según la plataforma y cómo elija integrar el inicio de sesión con Facebook:

Web

• Facebook SDK for JavaScript utiliza una opción scope con la llamada a la función FB.login.
• El botón "Iniciar sesión" utiliza un parámetro scope o data-scope en el elemento fb:login-button.
• Un flujo de inicio de sesión integrado manualmente debería añadir el parámetro scope a la URL del cuadro de diálogo de inicio de sesión a la que redirige.

Aplicaciones para móviles

• El inicio de sesión en Android puede utilizar varias clases diferentes para solicitar y administrar permisos. Para obtener más información, consulta nuestro tutorial de inicio de sesión para Android.
• El inicio de sesión en iOS puede utilizar varios métodos diferentes para solicitar permisos. Para obtener más información, consulta nuestro tutorial de inicio de sesión para iOS.
• Windows Phone utiliza el parámetro scope al lanzar la asociación de URI.

Ten en cuenta que muchas de las API enumeradas anteriormente también se pueden utilizar para solicitar permisos adicionales más adelante durante la vigencia de una aplicación, no solo en el primer inicio de sesión.

Optimización de las solicitudes de permisos

Como regla general, cuantos más permisos solicite tu aplicación, menos probable será que las personas utilicen Facebook para iniciar sesión en esta. De hecho, nuestros estudios revelan que las aplicaciones que solicitan más de cuatro permisos experimentan una reducción significativa del número de inicios de sesión completados.

Normas

A continuación se incluyen algunas directrices que se pueden utilizar al solicitar permisos, tanto durante el inicio de sesión como después de este:

• Solicitar solo los permisos esenciales para una aplicación.

• Solicitar un permiso en el contexto en el que es necesario. Por ejemplo, si tu aplicación quiere mostrar lugares de interés cerca de la ubicación de una persona, solicitar user_location justo antes de mostrar esa información proporciona a la persona una mejor comprensión de los motivos por los que se solicita el permiso.

• Separa la solicitud de los permisos de lectura y publicación. Puedes obtener más detalles a continuación.

• Nunca solicites permisos que creas que necesitarás en el futuro. Las personas podrían sospechar y rechazar tu aplicación.

• Explica a las personas con antelación por qué solicitas un permiso. Explicar por qué necesitas acceso a algo aumentará las posibilidades de que quieran compartirlo.

Permisos de publicación

Las aplicaciones deben separar la solicitud de permisos de lectura y de publicación. Al planificar tu aplicación, solicita los permisos de lectura mínimos indispensables en el inicio de sesión inicial y, posteriormente, los permisos de publicación cuando una persona realmente los necesite; por ejemplo, al intentar crear una historia de Open Graph desde la aplicación. Este enfoque proporciona la mejor experiencia de usuario y optimiza la conversión.

En el caso excepcional de que tu aplicación requiera permisos de publicación de antemano (por ejemplo, una aplicación que solo publica el estado de ánimo de una persona en Facebook), solicita solo los permisos de lectura mínimos indispensables en el inicio de sesión inicial. Cuando la persona haya iniciado sesión, muéstrale una pantalla en la que se explique por qué la aplicación necesita permisos de publicación y un botón que le permita aceptar la solicitud de estos permisos. De este modo, tendrá más contexto y mejorará tu conversión.

Un caso en el que puedes solicitar permisos de lectura y escritura seguidos es la primera vez que asocias una cuenta basada en correo electrónico con la cuenta de Facebook de una persona. Esto se hace, normalmente, cuando alguien quiere compartir una historia en su biografía de Facebook. Cuando la aplicación cree el cuadro de diálogo de inicio de sesión, la persona verá dos cuadros de diálogo seguidos: uno para conectar su cuenta con la aplicación y otro que solicita permisos de publicación. En este caso, asegúrate de que los únicos permisos de lectura que solicites sean public_profile. De este modo, proporcionarás la mejor experiencia de usuario, ya que el usuario quiere realizar publicaciones desde la aplicación y a menudo no tiene interés en proporcionar permisos de lectura adicionales. También mejorará tu conversión.

Comprobar los permisos actuales

Facebook ofrece a las personas control absoluto sobre los permisos que conceden a una aplicación. Ese control se prolonga más allá del momento en que ven el cuadro de diálogo de inicio de sesión. Pueden optar por no conceder determinados permisos durante el proceso de inicio de sesión. También pueden revocar los permisos desde su configuración de privacidad de Facebook en cualquier momento. Las aplicaciones deben comprobar la validez de los permisos antes de intentar realizar una llamada a la API en la que se requieren. Por ejemplo, comprobar que el permiso email sigue concedido antes de enviar un mensaje de correo electrónico.

Para las aplicaciones web, proporcionamos un extremo de API Graph para recuperar una lista de los permisos concedidos:

GET /{user-id}/permissions

La llamada debe realizarse con un identificador de acceso de usuario o con el identificador de acceso a la aplicación. La llamada devolverá una cadena JSON que contiene los nombres de permisos que se han concedido a la aplicación y su estado:

{
  "data": [
    {
      "permission": "public_profile",
      "status": "granted"
    },
    {
      "permission": "email",
      "status": "granted"
    },
    {
      "permission": "user_friends",
      "status": "declined"
    }
  ]
}

También proporcionamos métodos en los SDK de iOS y Android que proporcionan representaciones para la plataforma de los permisos que se han concedido a tu aplicación.

Gestionar los permisos que faltan

Cuando una aplicación solicita permisos, las personas pueden denegarlos completamente, no concederlos por completo o cambiarlos más adelante. Para poder proporcionar una excelente experiencia, las aplicaciones deben estar compiladas para gestionar estas situaciones.

En primer lugar, las aplicaciones deben poder gestionar los permisos solicitados pero no concedidos:

• Comprueba los permisos concedidos antes de intentar utilizar las API que los requieren.
• Detecta los errores de permisos devueltos cuando se realiza una solicitud de API sin el permiso correcto. El siguiente es un ejemplo de error:

{
  "error": {
    "message": "(#200) The user hasn't authorized the application
     to perform this action",
    "type": "OAuthException",
    "code": 200
  }
}

Si la aplicación detecta que alguien ha denegado alguno de los permisos o todos, puede volver a pasarlos a través del proceso de inicio de sesión una vez y solicitar todos los permisos necesarios. No obstante, esta experiencia no es recomendable y debe evitarse si es posible. Si alguien elige activamente no conceder un permiso específico a una aplicación, es poco probable que cambie de opinión, incluso ante solicitudes constantes. En su lugar, haz lo siguiente:

• Si una persona rechaza el cuadro de diálogo de inicio de sesión, proporciona una explicación clara con antelación sobre por qué solicitas cada permiso. A continuación, permite que pulse o haga clic en un botón para volver al cuadro de diálogo de solicitud de permisos. No la redirijas inmediatamente a un cuadro de diálogo de solicitud de permisos sin una explicación.

• Si alguien ha rechazado un permiso para tu aplicación, el cuadro de diálogo de inicio de sesión no permitirá que la aplicación vuelva a solicitar el permiso salvo que envíes auth_type=rerequest con la solicitud.

• En los casos en que alguien ha concedido algunos permisos, pero no otros, solicita solamente los permisos que faltan cuando sea necesario. Por ejemplo, si la aplicación envía confirmaciones de pedidos al correo electrónico de los usuarios, solicita el permiso email solo cuando realicen un pedido.

• Salvo que los permisos que solicitas en el cuadro de diálogo de inicio de sesión sean críticos para la funcionalidad de la aplicación y una función no pueda ejecutarse sin estos, permite que las personas sigan utilizando la aplicación sin los permisos.

Revocar permisos

Las aplicaciones pueden permitir que las persones revoquen permisos que se habían concedido anteriormente. Por ejemplo, la aplicación puede tener una página de configuración que permita que alguien desactive el envío de mensajes de correo electrónico. Esta página de configuración también podría revocar el permiso email al mismo tiempo.

Para revocar un permiso específico, puedes realizar una llamada a un extremo de API Graph:

DELETE /{user-id}/permissions/{permission-name}

Esta solicitud debe realizarse con un identificador de acceso de usuario o un identificador de acceso a la aplicación para la aplicación actual. Si la solicitud se realiza correctamente, recibirás una respuesta true.

Revocar el inicio de sesión

También puedes permitir que las personas desautoricen completamente una aplicación o revoquen el inicio de sesión mediante una llamada a este extremo de la API Graph:

DELETE /{user-id}/permissions

Esta solicitud debe realizarse con un identificador de acceso de usuario o un identificador de acceso a la aplicación válido para la aplicación actual. Si la solicitud se realiza correctamente, la aplicación recibirá una respuesta true. Si la llamada se realiza correctamente, cualquier identificador de acceso de usuario de la persona se invalidará y tendrá que volver a iniciar sesión. Dado que estás desautorizando tu aplicación, también tendrá que conceder acceso a tu aplicación como si estuviera iniciando sesión por primera vez.

Guías por plataforma