Facebookログイン Version2.0(アプリのパーミッション仕様変更)

5.8
2014

10333109_1431654790418445_296535717_n

先日Facebookから発表がありましたが、Facebook Login、アプリケーションへの権限付与などについて仕様変更がありました。

The New Facebook Login and Graph API 2.0
https://developers.facebook.com/blog/post/2014/04/30/the-new-facebook-login/

将来的には匿名でログインするようなことも可能なようですが、ひとまず現時点でも一部の権限取得フローに仕様変更がありましたのでまとめます。

詳細な情報は公式のドキュメントを見てもらうとして、注意すべき点のみを覚書として。

Permissions with Facebook Login
https://developers.facebook.com/docs/facebook-login/permissions/v2.0

デフォルトでアプリケーションがユーザーから取得できる「パーミッション」の種類が、大幅に制限された

10173501_712654372111832_803467338_n

スパムアプリ対策なのでしょうか。
「公開プロフィール情報(public_profile)」「メールアドレス(email)」「いいね!リスト(user_likes)」「友達リスト(user_friends)」以外のパーミッションは、全て申請をして受理されないと使えなくなりました。

特に影響がありそうなのは、、ユーザーにウォール投稿してもらうための権限「publish_actions」でしょうか。
なお、「publish_stream」「photo_upload」というパーミッションはどちらも廃止され、「publish_actions」に統合されています。

他にも、プロフィールの中でも少し踏み込んだ情報にアクセスしたい場合は申請が必要です。
申請は基本的には7営業日以内、一部の権限については14営業日以内での承認。
「publish_actions」は7営業日とのこと。

「パーミッション」の申請方法について

permission-change1

アプリの管理画面から、Status & Reviewより申請できます。
デフォルトで利用可能なパーミッションは既に追加済みで、必要に応じて「Submit Items for Approval」より。

Review Guidelines
https://developers.facebook.com/docs/apps/review

申請時には、所定の必要事項を英文で記載する必要があります。
また、SettingとApp Details内のいくつかの項目が埋まっていないと、申請出来ません。
詳細は上記のガイドラインに画面キャプチャ付きで紹介されています。

なお、当然アプリの審査を依頼する際には、アプリの動作や表示を確認出来る必要があるので、テストページ等のURLなどをFacebookに伝える必要があります。
この際、ファンゲートやBASIC認証などがかかっていると、テストユーザーによるアクセスが出来ないために審査が差し戻しになりますのでご注意を。

※6/10追記:
実際に「publish_actions」を申請し、審査通過したフローや注意点などを別記事でまとめました。
Facebookアプリのパーミッション「publish_actions」を申請してみてわかったことまとめ

※6/27追記:
パーミッションの審査通過前でも、テストユーザーを使えば動作チェックできます。
Facebookアプリのテストユーザーを利用してpublish_actions等を審査前に動作確認する

「Publish」権限の取得フローについて

スパムアプリの横行によりユーザーからのクレームが多かったのか、タイムラインへの投稿時に必要な「Publish」権限の取得についてはかなりシビアにガイドラインが規定されています。
851557_535801936465660_169463870_n

Only ask for the permissions that are essential to an app.

本当に必要な権限のみ取得する

Ask for permission in the context in which they are required. For example, if your app wants to show places of interest near a person’s home, asking for user_place_visits just prior to displaying that information would give the person a greater understanding of why the permission is being requested.

ユーザーが違和感なく権限を渡せるように配慮する。
例えば、ユーザーの家の近くのおすすめスポットを表示するために、「user_place_visits」という権限を取得するように、文脈や字面から見てもユーザーが理解できるように設計をする。

Use any available public profile information before asking for a permission. For example, there is an age_range field included in the public profile for anyone who installs your app. This field may be sufficient for your app instead of requesting user_birthday permission.

特別なパーミッションを取得する前に、標準の「公開プロフィール(public profile)」を使って実現できないか検討すべし。
例えば、アプリ利用ユーザーの年齢層を知りたい場合には「user_birthday」を追加取得するのではなく、公開プロフィール内の「age_range」を使うべき。

Separate the request of read and publish permissions. For more details, see below.

Apps should separate the request of read and publish permissions. Plan your app around requesting the bare minimum of read permissions at initial login and then any publish permissions when a person actually needs them, for example when they want to create an Open Graph story from within the app.

読み取り権限と投稿権限は別々に取得する。
初回のログイン時には最低限の読み取り権限のみ取得し、ユーザーが実際に投稿する際に、投稿権限を取得するようなフローが望ましい。

Never ask for permissions you think you might need in the future. People will be suspicious and may reject your app.

(現在は使わないが、)近い将来必要になるだろう、という理由で権限を取得しないこと。

Tell people ahead of time why you are requesting a permission. Explaining why you need access to something will increase the chance that they are willing to share it.

ユーザーに対しては、事前に各種パーミッションを取得する理由を説明すべき。

In the rare case your app requires publishing permissions up front (for example, an app that does nothing but publish a person’s mood to Facebook) only request the bare minimum read permissions at initial login. After the person logs in, show the person a screen explaining why your app needs publishing permissions and let the person opt-in to the publishing permission request by clicking a button. This will provide them with more context and improve your conversion.

例えば、Facebookに今の気分を投稿するような、前もって投稿権限を必要とするようなアプリの場合でも、初回ログインの時点では最小限の読み取り権限に絞る。
ユーザーがログインした後で、投稿権限が必要な理由の説明と、オプト イン方式による権限の承認を求める。

One instance where you may have to request read and write permissions back-to-back is the first time that you’re associating an email-based account with a person’s Facebook account. This is usually done when someone wants to share a story on their Facebook Timeline.
When your app creates the login dialog, the person will see two dialogs in a row – one to connect their account to your app and another asking for publish permissions.
For this case, make sure that the only read permissions you request are public_profile. This provides the best user experience because the user wants to publish from your app and is often not interested in providing additional read permissions. It will also improve your conversion.

アプリ登録ユーザー(メールアドレスベース)とFacebookアカウントを関連付けるために、最初に読み取り権限と投稿権限を連続して表示するような場合。
権限の承認ダイアログが2回表示されることになる。(1回目は読み取り、2回目は投稿の権限)
このような場合には、読み取り権限で取得する情報は「公開プロフィール(public_profile)」のみとする事。
多くのユーザーは投稿権限以外に余計な情報の読み取り権限は渡したくないため。

取得した権限の利用と、再承認のフローについて

Apps should check for the validity of permissions before attempting to perform an API call where they are required. For example, checking that publish_actions is still granted before attempting to publish an Open Graph story.

(権限はいつでも拒否したりキャンセルすることが出来るので、)アプリは権限を必要とする場合には必ずユーザーの権限がまだ承認されている状態かどうかを確認する事。

First, apps should be able to handle any permissions that were requested but not granted:

アプリは必要とする権限を承認されなくとも、操作できるようにしなければならない。

Once an app has detected that someone has denied some or all permissions, it may pass them back through the login flow once and request any required permissions. However, this is a poor experience and should be avoided if possible. If someone is actively choosing not to grant a specific permission to an app they are unlikely to change their mind, even in the face of continued prompting.

権限の一部またはすべてを拒否しているユーザーには、1回だけ再度承認フローに飛ばすことが出来ますが、一度拒否しているユーザーに再度承認画面を出すのはあまり好ましくありません。

If a person declines the login dialog have a clear and upfront explanation about why you are requesting each permission. Then let them click or tap to opt back in to the permission request dialog. Do not immediately redirect them into a permission request dialog without an explanation.

ユーザーが権限を拒否する場合、何故その権限が必要なのかを明確に説明しましょう。
説明を見たうえで、ユーザーが再度権限の承認フローに戻れるようにします。説明なく、権限の承認フローを再表示するようなフローはNGです。

If someone has declined a permission for your app, the login dialog won’t let your app re-request the permission unless you pass auth_type=rerequest along with your request.

アプリの権限を拒否しているユーザーに対しては、「auth_type=rerequest」を利用しない限りユーザーに再度承認画面を表示することはできません。

For cases where someone has granted some permissions but not others, only prompt for missing permissions at the point at which they are needed. For example, if your app posts stories to Facebook, only request publish_actions when they ask to publish a story.

権限が不足している場合には、その不足している権限が必要な場面において、不足している権限のみをリクエストするようにしてください。

Unless the permissions you are requesting in the login dialog are critical to the functionality of your app and a feature doesn’t work without them, let people continue using your app without the permissions.

ある権限がアプリの機能や動作に致命的な影響を与えない限り、その権限が無くともユーザーにはアプリの利用を続けさせること。

まとめると、どうすればいいのか?

  • ユーザーがアプリにアクセス(ログイン)した際、初回には公開プロフィールのみを取得する
  • 投稿権限についてはかなりシビアなので、以下のいずれかの方法で取得する

    1. ユーザーが投稿可能な場面で、「投稿する」「シェアする」などのわかりやすいボタンを用意し、クリックした場合のみ投稿権限を取得
    2. 事前に「投稿権限」を取得する場合には、前もってユーザーに説明をしたうえで、オプトイン形式で権限取得を行う
  • 権限を拒否したユーザーにたいして再承認を依頼する際には権限が必要な理由を説明しつつ、「auth_type=rerequest」を使う
  • 権限を拒否したユーザーでも、アプリへのアクセス等は可能にする

よくある、何かのアクションをしたら裏で自動的にポストされているようなものは、基本的にはこのガイドラインではすべてアウトですね。
もちろん、Platform Policyの規定に違反しているものは論外ですが、そちらに適合していても権限周りのガイドラインに即していなければ結局ダメです。

実際のところポリシーとは異なりガイドラインに書かれている内容はすべてクリアしていなくてもいきなりアプリを止められたり制限されることはありませんが、このところかなり厳しくなってきているのでガイドライン通りに設計しないといきなり止められても文句言えなそうです。

投稿権限を取得せずにユーザーのタイムラインに投稿する

permission-change2

publish権限を取得せずに、ユーザーのタイムラインに投稿する方法もあります。
Share Dialog(旧Feed Dialog)を使う方法です。
過去にsharer.phpを使う方法やFeed Dialogを使う方法などが示されてきましたが、現在はShare Dialogを使うんですね。

Share Dialog
https://developers.facebook.com/docs/sharing/reference/share-dialog

Shareメソッドと、Share open graphとありますが、アクションタイプが「シェア」でよければ前者で構いません。
後者のShare open graphを使えば、カスタムアクションにも対応できます。