Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」ではアプリからの投稿周りで多用するパーミッション2つの違いを紹介しましたので、ここでは認証ダイアログをおさらいして、そこでの両パーミッションの違いを紹介します。

新・認証ダイアログは2画面構成

3/9から強制以降が始まった新・認証ダイアログは、「User and Friends Permissions(ユーザ自身と友だちに関するパーミッション)」と「Extended Permissions(追加のパーミッション)」の2画面構成となっていて、それぞれ役割が違います。ここでは、email, publish_actions, user_birthday, read_friendlistsの4つのパーミッションを要求するものとして進めます。

User and Friends Permissions

これは認証ダイアログの1ページ目にあたる部分です。アプリが要求するパーミッションのうち、ユーザ自身と友だちの情報に関するパーミッションがここに表示されます。最低限の読み込み系が多く、書き込み系のパーミッションはあまり扱われませんが、publish_actionsはここで要求されます
次のステップへ進んでアプリを利用するには、ユーザはここに表示される全部のパーミッションを許可しなくてはなりません。パーミッション一覧や下のキャプチャを見ると分かりますが、ユーザのメールアドレスを求めるemailパーミッションもこのページに表示されます。
auth-test
必要なさそうなパーミッションまで要求されると、ユーザが躊躇してそこで終わってしまいますので、要求しすぎないことが大切です。

Extended Permissions

こちらは2ページ目にあたる部分で、ユーザに取って影響の大きいパーミッションが扱われます。ユーザの友だちリストやメールボックスを読み込むパーミッションや、イベントを作成するパーミッションなどが要求されるほか、publish_streamもここで要求されます
1ページ目との動作の違いは、このページではどのパーミッションを許可するかユーザが選択できる点です。
auth-test2
キャプチャを見ると分かる通り、右側に「x」が表示され、これを押すことで個々のパーミッションリクエストを拒否することができます。
auth-test3
そこで注意しなくてはならないと思うのは以下の2点です。
  • 認証が完了したからと言って、要求したパーミッションが全部与えられているとは限らない
    (私の場合、まだ友だちが使っていないアプリだったりすると、どんな内容が投稿されるのか想像がつかないのでpublish_streamを躊躇ってしまいます。)
  • 拒否したパーミッションは次回移行の認証でも毎回要求されるので、ユーザ自身で選択できて親切とは言え、かなりうっとおしい
拒否した分を次回以降も要求されるので、こちらの場合でもやはり、必要以上に要求しないことが大切です。

パーミッションと認証ダイアログのまとめ

前回の記事と今回の認証ダイアログのまとめは以下の通りです。

ダイアログのページ

まず、認証ダイアログの1ページ目と2ページ目を意識するという点。publish_actionsは認証ダイアログの1ページ目でpublish_streamは2ページ目ですから、投稿系のパーミッションをpublish_actionsですませることが出来れば、認証ダイアログは1ページで済ませられるかもしれません。
また、間違ってpublish_actionsとpublish_streamの両方を要求すると、その要求はpublish_actionsの上位にあたるpublish_streamの要求へとマージされます。これは2ページ目に表示されますので、ユーザは拒否することが可能となってしまい、publish_actionsにしておけば必ず許可してもらえたチャンスを逃してしまいます。

必要なときに必要なパーミッションをリクエスト

もう一点大事なことは、必要なときに必要なパーミッションのみ要求することだと思います。アプリのインストール時には全ユーザに共通して必要となる最低限のパーミッションのみ要求し、あとは設定画面を設けておいて、On / Offの切り替え時に適宜要求するなどです。Kloutは最初のログイン時はフィード読み込みなどのパーミッションしか要求せず、設定画面でFacebook共有をOnにするときに初めて投稿系パーミッションを要求します。自分の影響度という繊細な部分を扱うサービスなので、最初から投稿系パーミッションを要求されると、自分の影響度が勝手に投稿されると感じてためらうユーザもいるでしょうから、そのようなユーザの不安を避ける上でも参考になる実装例だと思います。
On / Offを切り替える際、ユーザがすでに該当するパーミッションを許可しているか否かを把握し、必要に応じてパーミッションを要求する必要がありますが、それに関しては3番目のエントリで紹介します。
(※あとから追加でパーミッションを要求する場合は、追加で要求するパーミッションのみscopeに指定して認証ダイアログに飛ばせば大丈夫です。他のパーミッションをscopeに指定しなかったからといって、既に許可されたパーミッションが消されてしまうことはありません。)

(発表では新・認証ダイアログの詳細な設定については省きましたが、ドキュメントは和訳:Auth Dialogをご覧ください。)

実装する

これらを踏まえてアプリ開発を進めようとすると、publish_streamが許可されなかったのに「友だちのウォールに投稿」ボタンを表示してしまうことが無いよう、認証完了時にユーザがどのパーミッションを許可しているのか把握する必要があります。
また、アプリ利用開始時には許可していたパーミッションでも、Facebook上のプライバシー設定ページから消されてしまうことがありますので、それを把握する必要も出てきます。
それらの実装方法については、「Facebook Night Vol.7 発表内容まとめ3 Batch RequestとReal-time Update API」で紹介します。