3

私の理解では、facebook API のレート制限は、トークンと IP ごとに、600 秒あたり約 600 回の呼び出しです。現在、ユーザーがページを閲覧するためにログインする必要のない公開ナイトクラブのページやイベントを閲覧できるウェブサイト/facebook-app があるので、そのためにアプリ トークンを使用します。しかし、ユーザーが自分のアカウントが Facebook グラフと対話する Web サイト/アプリの機能を使用できるようにするには、ログインする必要があるため、そのためにユーザー トークンを使用します。

そのため、ユーザーがログインしている場合、レート制限を超えても問題はありません。これは、各ユーザーが異なるユーザー トークンを持ち、各ユーザーが 600 秒あたり 600 コールのレート制限を持つためです。しかし、私の懸念は、ユーザーがログインしていないときに公開ナイトクラブのページやイベントを閲覧しているときに、アプリがレート制限を超えてしまうことです。これは、1 つのアプリ トークンと 1 つの IP アドレス (私のサーバー) が複数のユーザーに使用されるためです。一度に複数のユーザーが公開のナイトクラブ ページやイベントを閲覧している場合、レート制限を簡単に超えてしまいます。

私はいくつかの調査を行い、クライアント側から API 呼び出しを行うことができることを発見しました。これにより、パブリック ナイトクラブのページとイベントを閲覧しているユーザーごとに異なる IP アドレス (ユーザーのコンピューター) が存在するため、各ユーザーは600 秒あたり 600 回の呼び出しのレート制限があります。しかし、クライアント側から API 呼び出しを行った場合、アプリ トークンとアプリ シークレットはユーザーに表示されますか? これはセキュリティ上のリスクになりますか? これが正しいかどうかは誰でも確認できますか?ユーザーが公共のナイトクラブのページやイベントを閲覧しているときに、レート制限を超えないようにするために他にできることはありますか? 前もって感謝します。

4

1 に答える 1

1

クライアント側から呼び出しを行う場合、アプリ シークレットは提供しません。クライアントはアプリにログインしているため、クライアントは関係なく表示できるアプリ ID のみを提供します。アプリの Facebook Cookie には、アプリ ID が含まれています。各クライアントは独自のトークンを取得し、それを確認することもできます。

「ナイトクラブのページを閲覧する」というのが技術的に何を意味するのかはわかりませんが、JavaScript を使用してサーバーの作業をクライアントにオフロードできるのであれば、それが望ましいです。また、サーバー側でユーザーを認証するときは、すべてのページ リクエストで $facebook->getUser() を呼び出さないようにしてください。これは、API の制限に反するためです。可能であれば、JavaScript を使用してクライアントにログインしてみてください。そうでない場合は、FB サーバー側で一度ログインしてから、独自のセッションを設定して、サイトでクライアントを認証してください。これにより、API 呼び出しが大幅に削減されます。

この質問を参照してください: API 呼び出しが最小限の Facebook アプリの構造

于 2013-04-26T07:24:46.553 に答える