0

Facebook アプリ シークレットと、同じアプリ ID/シークレットを使用できる個別の接続 (または「アプリケーション」) の数に関して、ボリュームの問題はありますか? たとえば、SharePoint 自動ホスト Facebook アプリケーションを作成しています。自動ホストとは、アプリのサーバー コンポーネントが各 SharePoint 顧客の Azure に自動的にデプロイされることを意味します。ユーザーがアプリの ID やシークレットを取得できる方法はありません (私が知っていることですが、明らかに何でもある程度ハッキング可能です)。そのため、セキュリティ面やシークレットの共有については心配していません。ただし、何千もの個別のアプリが同じアプリ ID/シークレットを使用して Facebook に接続している可能性があります。これは問題ですか？

ところで、必ずしも帯域幅/トラフィックのしきい値について話しているわけではありません。同じ ID/シークレットを使用する個々の接続の数に関心があります。ポリシーに次のように記載されていることを認識しています。「次のしきい値のいずれかを超えるか、超える予定がある場合は、追加の条件が適用される可能性があるため、お問い合わせください: (>5M MAU) または (>100M API 呼び出し/日) または ( 1 日あたり 5,000 万回以上のインプレッション)。」これは私の差し迫った関心事ではありません。

4

1 に答える 1

0

However, potentially thousands of individual apps could be using the same app id/secret to connect to Facebook. Is this an issue?

はい、絶対にそうです。

アプリ アクセス トークンは、アプリ自体に代わって呼び出しが行われたことを証明するために、アプリに代わって API 呼び出しを行うことを目的としています。一般的なユース ケースは、ユーザー プロファイルからのアプリのアンインストールやアプリのブロック、更新などの管理アクションの実行です。アプリの設定、許可されたユーザーへの通知の送信、アプリの支払い取引に関する財務データの読み取りなど。

アプリ アクセス トークンを使用して読み取り呼び出しを行うことを計画している場合は、Facebook の API で使用されるアクセス モデルを誤解していると思われます。アプリにアクセス許可を付与した特定の Facebook ユーザーに代わって API 呼び出しを行う必要があります。データを更新する - 広く配布しているコードにアプリ ID とシークレットを埋め込むことは、アプリのユーザーにとってセキュリティ上の問題であり、すぐに API レート制限に達し、アプリがシャットダウンされると、クライアント コードのすべてのインスタンスがすぐに壊れます。

ログインのドキュメントを読み、ユーザー アクセス トークンを使用してユーザー データを要求していることを確認することを強くお勧めします - https://developers.facebook.com/docs/facebook-login/

于 2013-10-04T00:21:33.030 に答える