キャンバスアプリの次の状況を想定します。
i）1日目：-
read_stream,publish_stream,offline_access権限が必要なFacebookアプリが作成されます。ユーザーが初めてアプリにアクセスしたとき、authorize呼び出しはユーザーを許可の許可/拒否画面にリダイレクトし、ユーザーが許可したときにユーザーをキャンバスのURLにリダイレクトします。
キャンバスURLのリクエストパラメータには、署名されたリクエストのaccess_tokenがあり、アプリの実行に使用できます。
ユーザーが過去にアプリを承認したことがある場合、signed_requestにはacess_tokenが含まれているため、次回アプリにアクセスする同じユーザーに権限ダイアログは必要ありません。
コードは次のようになります。
if(access_token received from signed request)
// do something with user information
else
// redirect user for authorization flow
user_birthday
ii）2日目：-ここで、リストにもう1つの権限、 read_stream、publish_stream、offline_access、user_birthday`を追加したいとします。次のロジックで問題が発生します。
if(access_token received from signed request)
// do something with user information <-- the access_token does not have new permission
else
// redirect user for authorization flow
API呼び出しはアプリのパフォーマンスに影響を与えるため、この追加の権限の追加に効率的に取り組むにはどうすればよいですか？私は次のようなものを使いたくありません：
https://graph.facebook.com/me/permissions?access_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
アプリケーションが読み込まれるたびに、トークンに関連する権限を確認します。
アップデート：
良い方法を共有する：アクセス許可セットを、それを受け取ったaccess_tokenと一緒に保存します。例えば。現在のアクセス許可が「basic_details-birthday-publish」（1と呼びます）の場合、access_tokenとアクセス許可セットを次のように保存します。
user | access_token | perm_set
Dhruv sdfsdfsdf 1
これで、設定で、新しいアクセス許可を要求する必要があるときはいつでも、新しいアクセス許可セット「basic_details-birthday-publish-checkins」（2と呼びます）を作成します。
次に、perm_set =1のアクセストークンを持っているユーザーに対してのみアクセス許可ダイアログを表示する必要があります。すでにperm_set=2を持っているユーザーの場合は表示しません。これにより、「/ me/permissions」を使用して各ユーザーのaccess_tokenを確認する必要がなくなります。 api。