Запрос и отзыв разрешений

Для каждого типа процесса входа используется собственный метод запроса разрешений. Он зависит от платформы и способа интеграции входа через Facebook.

Веб-версия

Facebook SDK для JavaScript использует параметр scope с вызовом функции FB.login.
Кнопка "Вход" использует параметр scope или data-scope в элементе fb:login-button.
Процесс входа, созданный вручную, должен добавить параметр scope в URL диалога входа, на который происходит перенаправление.

Мобильные приложения

Вход для Android может использовать разные классы для запроса разрешений и управления ими. Подробнее см в руководстве по входу для Android.
Вход для iOS может использовать разные методы для запроса разрешений. Подробнее см. в руководстве по входу для iOS.
Windows Phone использует параметр scope при запуске сопоставления URI.

Обратите внимание: большинство перечисленных выше API также можно использовать для запроса дополнительных разрешений в течение жизненного цикла приложения, а не только сразу при входе.

Оптимизация запросов на получение разрешений

Как правило, чем больше разрешений запрашивает приложение, тем меньше вероятность, что люди будут входить в него через Facebook. Наши исследования показывают, что люди значительно реже завершают вход в приложение, если оно запрашивает больше четырех разрешений.

Разрешения на публикацию

Приложения должны запрашивать разрешения на чтение и на публикацию отдельно. Запрашивайте минимум разрешений на чтение при первом входе пользователя, а за разрешениями на публикацию обращайтесь, только если возникает потребность в них, например когда человек хочет создать в приложении новость Open Graph. Это создаст у пользователя хорошие впечатления и позволит оптимизировать конверсию.

Если приложение подряд запрашивает разрешения на чтение и публикацию, вы можете получить оповещения для разработчиков. Чтобы не получать их в дальнейшем, разнесите запросы во времени или следуйте приведенным далее инструкциям для исключительных случаев.

Иногда приложению изначально необходимы разрешения на публикацию, например если оно предназначено только для того, чтобы люди делились сиюминутными впечатлениями на Facebook. Тогда запрашивайте при первом входе минимум разрешений на чтение. После входа покажите человеку экран с пояснением, зачем приложению нужны разрешения на публикацию. Пусть он сам нажмет кнопку, чтобы принять этот запрос. Таким образом, вы предоставляете человеку дополнительный контекст и улучшаете показатель конверсии.

Единственный случай, когда вам необходимо сразу запросить разрешения на чтение и запись, — при связывании аккаунта на базе электронной почты с аккаунтом Facebook пользователя. Обычно это происходит, когда кто-то хочет опубликовать новость в своей Хронике Facebook. Если приложение создает диалог входа, человек увидит два окна подряд: одно свяжет его аккаунт с вашим приложением, а другое запросит разрешения на публикацию. В этом случае вы должны запрашивать только одно разрешение на чтение: public_profile. Это удовлетворит пользователя, потому что он планирует размещать публикации из вашего приложения и зачастую не заинтересован в том, что предоставлять дополнительные разрешения на чтение. Кроме того, это позволит улучшить показатель конверсии.

Проверка текущих разрешений

Facebook позволяет людям самим решать, какие разрешения предоставить приложению. Причем возможности контроля распространяются не только на диалог входа. Пользователи могут отказаться предоставить часть разрешений в процессе входа. Они также могут в любой момент отозвать разрешения в своих настройках конфиденциальности Facebook. Если для вызова API требуются разрешения, приложение сначала должно проверить, действуют ли они. Например, перед отправкой сообщения нужно убедиться, что разрешение email по-прежнему действует.

Веб-приложения могут получить список предоставленных разрешений, используя конечную точку API Graph:

GET /{user-id}/permissions

В вызове необходимо указать маркер доступа пользователя или приложения. Вызов возвращает строку JSON, которая содержит имена предоставленных приложению разрешений и их состояние:

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

Кроме того, наши SDK для iOS и Android позволяют представить предоставленные разрешения в соответствии с особенностями конкретной платформы.

Работа с недостающими разрешениями

В ответ на запрос разрешений человек может вообще отказаться их предоставлять, предоставить их не полностью или позднее изменить свое решение. Для успешной работы приложение должно уметь обрабатывать такие ситуации.

Прежде всего необходимо определить, какие разрешения были запрошены, но не предоставлены.

Проверьте предоставленные разрешения, прежде чем обращаться к API, которые их используют.
Отслеживайте ошибки разрешений, которые возвращаются в ответ на запросы API, отправленные без соответствующего разрешения. Вот пример такой ошибки:

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

Обнаружив, что разрешения отменены частично или полностью, приложение может один раз запустить процесс входа и вновь запросить нужные разрешения. Однако делать так не рекомендуется, и по возможности таких ситуаций следует избегать. Если человек упорно отказывается предоставить определенное разрешение, он вряд ли изменит свое мнение, даже если вы будете настойчиво повторять запрос. Вместо этого поступите, как описано ниже.

Если человек отклоняет запрос на разрешения в диалоге входа, покажите заранее подготовленное четкое пояснение, зачем вам нужно каждое из них. После этого дайте пользователю возможность самому нажать кнопку, чтобы вернуться к диалогу запроса разрешений. Не перенаправляйте людей сразу к этому диалогу без каких-либо объяснений.
Если человек отказался дать разрешение, диалог входа не позволит приложению сделать повторный запрос, если только вы не передадите вместе с ним параметр auth_type=rerequest.
Если пользователь предоставил не все разрешения, запрашивайте только недостающие, причем тогда, когда в них возникнет потребность. Например, если ваше приложение отправляет подтверждение заказа по электронной почте, запрашивайте разрешение email только при оформлении заказа.
Если разрешения, которые запрашиваются в диалоге входа, не критичны для работы вашего приложения и оно может обойтись без них, позвольте людям пользоваться приложением без разрешений.

Если ваше приложение постоянно направляет пользователей в диалоги запроса разрешений после отказа их предоставить, вы можете получать оповещения для разработчиков. Чтобы они перестали приходить, следуйте этим рекомендациям.

Отзыв разрешений

Приложение может позволять пользователям отзывать ранее предоставленные разрешения. Например, в вашем приложении может быть страница настроек, где человек может отключить отправку ему электронных писем. Одновременно с этой страницы может отзываться разрешение email.

Чтобы отозвать конкретное разрешение, отправьте вызов к конечной точке API Graph:

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

В запросе необходимо указать маркер доступа пользователя или текущего приложения. В случае успешного выполнения запроса вы получите ответ true.

Отзыв входа

Вы также можете разрешить людям полностью отозвать все разрешения для приложения, т. е. отозвать вход. Для этого выполните вызов к конечной точке API Graph:

DELETE /{user-id}/permissions

В запросе необходимо указать действительный маркер доступа пользователя или текущего приложения. В случае успешного выполнения запроса приложение получит ответ true. При успешном вызове маркер доступа конкретного пользователя станет недействителен, и человек должен будет войти в приложение снова. Поскольку вы деавторизовали приложение, этому пользователю необходимо будет предоставить такой же доступ, как если бы он входил в приложение впервые.

Руководства для платформ

Android iOS Веб-версия