ログインフローの種類ごとに、アクセス許可をリクエストするためのそれぞれ独自の方法があります。それは、プラットフォームに応じて、またFacebookログインをどのように統合するかに応じて異なります。
FB.login
関数呼び出しでscope
オプションが使用されます。scope
パラメーターを追加しなければなりません。scope
パラメーターが使用されます。上記のAPIの多くは、初期ログイン時だけでなく、アプリの存続期間中、後から追加のアクセス許可を依頼するためにも使用できることに注意してください。
一般に、アプリがリクエストするアクセス許可が多ければ多いほど、人々がアプリにログインするのにFacebookを使う見込みが少なくなります。事実、Metaの調査では、5つ以上のアクセス許可のリクエストがあると、利用者がログインを完了する割合が非常に少なくなります。
ログイン中とログイン後の両方について、アクセス許可リクエストを行う際に使用するべきいくつかのガイドラインを以下に示します。
アプリにとって本当に必要なアクセス許可だけをリクエストしてください。
アクセス許可は、それが必要とされるコンテキストでリクエストしてください。例えば、人の現在地の近くで何らかの目的に関係した場所を表示するアプリの場合、その情報を表示する直前にuser_location
をリクエストするなら、その人にとって、そのアクセス許可がなぜリクエストされるのかを理解しやすくなります。
読み取りアクセス許可と投稿アクセス許可は、別個に扱ってください。詳しくは、下記をご覧ください。
将来必要になると考えているアクセス許可をリクエストすることは、決してしないでください。人々は何か怪しいと考えてアプリを使わないことにするかもしれません。
あるアクセス許可をリクエストする理由について、事前に伝えるようにしてください。特定のものになぜアクセスする必要があるかを説明するなら、シェアしても良いと思う可能性が高くなります。
アプリでは、読み取りアクセス許可と投稿アクセス許可のリクエストを別個に行うようにしてください。初期ログイン時には最低限の読み取り許可をリクエストし、投稿アクセス許可はその人が実際に必要になった時点(アプリ内からOpen Graphストーリーを作成する時点など)でリクエストするように、アプリを設計してください。それにより、ユーザーエクスペリエンスがベストなものとなり、コンバージョンが最適化されます。
立て続けに読み取りアクセス許可と投稿アクセス許可をアプリからリクエストすると、開発者アラートになる場合があります。それらのアラートが出ないようにするには、リクエストを分離するか、または例外的なケースでは下記のガイドラインに従うようにしてください。
まれなケースとして、アプリで投稿アクセス許可を事前に必要とする場合(気分をFacebookに投稿するだけのアプリなど)、初期ログインでは最低限の読み取りアクセス許可のみリクエストしてください。ログイン後、アプリでなぜ投稿アクセス許可が必要かを説明する画面を表示し、ボタンをクリックすれば投稿アクセス許可リクエストをオプトインできるようにしてください。これにより提供されるコンテキスト情報が多くなり、コンバージョンが向上します。
読み取りアクセス許可と書き込みアクセス許可を立て続けにリクエストすることが必要になると思われる1つのケースは、メールベースのアカウントをその人のFacebookアカウントに初めて関連付ける場合です。通常これは、自分のFacebookタイムライン上のストーリーをシェアしたいという場合です。アプリでログインダイアログを作成すると、2つのダイアログが続けて表示されます。1つは、そのアカウントをアプリに結び付けるため、もう1つは投稿アクセス許可をリクエストするためのものです。その場合、リクエストする読み取りアクセス許可はpublic_profileだけにしてください。これによりユーザーエクスペリエンスがベストなものとなります。というのも、ユーザーが求めているのはアプリから公開することであり、追加の読み取りアクセス許可についてはどうでもいいと考えていることが多いからです。また、それによってコンバージョンも向上します。
Facebookでは、アプリに付与するアクセス許可について、ユーザー自身がすべてコントロールできるようにしています。ログインダイアログが表示された後でも、コントロールできます。ログイン処理中に特定のアクセス許可を付与しないことを選ぶことが可能です。さらに、Facebookプライバシー設定の中で、いつでもアクセス許可を取り消すことができます。アプリでは、API呼び出しをする前に、必要とするアクセス許可の有効性について確認するようにしてください。例えば、メッセージを送信する前に、email
がまだ付与されているか確認します。
ウェブアプリの場合、付与されているアクセス許可のリストを入手するためのグラフAPIエンドポイントが用意されています。
GET /{user-id}/permissions
その呼び出しでは、ユーザーアクセストークンかアプリアクセストークンのいずれかを使用する必要があります。この呼び出しから返されるのは、アプリに付与されているアクセス許可の名前とそのステータスを内容とするJSON文字列です。
{ "data": [ { "permission": "public_profile", "status": "granted" }, { "permission": "email", "status": "granted" }, { "permission": "user_friends", "status": "declined" } ] }
さらに、iOSとAndroidのSDKには、アプリに付与されているアクセス許可を、プラットフォームに応じた形で表すものを提供するためのメソッドが用意されています。
アプリからアクセス許可リクエストしたときに、ユーザーがことごとく拒否したり、一部しか付与しなかったり、または付与を後で変更したりする可能性があります。優れたエクスペリエンスを提供するため、アプリはそのような状況を処理するようになっていなければなりません。
まずアプリは、リクエストしたものの付与されなかったアクセス許可を処理できなければなりません。
{ "error": { "message": "(#200) The user hasn't authorized the application to perform this action", "type": "OAuthException", "code": 200 } }
アクセス許可の一部または全部が拒否されたことをアプリが検出したなら、一度ログインフローに戻って必要なアクセス許可をリクエストすることができます。しかし、これは良いエクスペリエンスとは言えず、できれば避けるようにしてください。アプリに対して特定のアクセス許可をあえて付与しない場合、繰り返して促したとしても、その人の気持ちが変わることはあまり期待できません。その代わり、次のようにしてください。
ログインダイアログを承認しない人に対しては、アクセス許可のそれぞれについてなぜ必要なのかを前もって明確に説明します。その上で、クリックやタップによりアクセス許可リクエストダイアログに戻れるようにします。説明しないまま、すぐにアクセス許可リクエストダイアログに戻らないようにします。
アプリにアクセス許可を承認しない人に対しては、リクエストとともにauth_type=rerequest
を渡すのでない限り、ログインダイアログでそのアクセス許可を再びリクエストしないようにします。
アクセス許可の一部しか付与しない人については、それらのアクセス許可が必要になった時点で欠落しているアクセス許可についてのみプロンプトを出します。例えば、アプリから注文確認メールをユーザー送る場合、注文した時点でemail
のみリクエストします。
ログインダイアログでリクエストするアクセス許可がアプリの機能に不可欠でありそれらなしでは機能しないというのでなければ、それらのアクセス許可なしでアプリを使い続けられるようにします。
ユーザーがアクセス許可を拒否した後、アプリでアクセス許可ダイアログを繰り返し表示すると、開発者アラートになる可能性があります。それらのアラートが出ないようにするには、これらのガイドラインに従ってください。
アプリでは、以前に付与されたアクセス許可を取り消せるようにすることができます。例えば、アプリの設定ページで、メールメッセージ送信を無効にできるようにするかもしれません。その設定ページで、同時にemail
アクセス許可を取り消すこともできます。
特定のアクセス許可を取り消すには、グラフAPIエンドポイントを呼び出します。
DELETE /{user-id}/permissions/{permission-name}
このリクエストでは、ユーザーアクセストークンか現在のアプリのアプリアクセストークンを使用する必要があります。リクエストが成功すると、true
を含む応答が返されます。
また、アプリの認証を完全に取り消したり、ログインを取り消したりすることもできます。そのためには、このグラフAPIエンドポイントを呼び出します。
DELETE /{user-id}/permissions
このリクエストでは、有効なユーザーアクセストークンか現在のアプリのアプリアクセストークンを使用する必要があります。リクエストが成功すると、応答としてtrue
がアプリに返されます。呼び出しが成功すると、その人のユーザーアクセストークンが無効になり、その人はもう一度ログインする必要があります。アプリの認証を取り消すことになるため、初めてログインする場合と同じように、アプリにアクセス許可を付与することも必要になります。