私はPHPで小さなCMSを開発しており、社会統合を進めています。
コンテンツは、ニュースやイベントなどを公開する権利を持つ1人の管理者によって変更されます...
管理者がFacebookのウォールにすでに投稿されているものを公開するときに、この機能を追加したいと思います。私はfacebookphpSDKにあまり詳しくないので、少し混乱しています。
（例として）10の異なるサイトが私のCMSを使用している場合、10の異なるFacebookアプリケーションを作成する必要がありますか？（10のWebサイトがすべて異なるドメインとサーバーにあると仮定しましょう）
2番目に、ユーザーがFacebookにログオンする必要がないように、PHPだけで認証する方法（ユーザー名とパスワードを直接送信するなど）はありますか？
ありがとう
質問を理解しやすい小さな単位に分割することをお勧めします。あなたが何を運転しているのかを理解するのは非常に難しいです。
あなたの問題についての私の理解は最小限かもしれませんが、ここに行きます...
1_いいえ、10種類のFacebookアプリケーションを作成しません。単一のFacebookアプリケーションを作成し、それをサービスのエントリポイントにします。すべてのcmsサイトがこの1つのサイトと通信して、Facebookとやり取りできるようにします。（RESTサービスレイヤー）。
2_Facebookapiはユーザー名とパスワードの認証をサポートしていません。それらはoauth2.0のみをサポートします。Oauthは簡単ではありませんが、そのためのライブラリを提供しているため、認証の実装は非常に簡単です。
http://developers.facebook.com/docs/で読んでください。
その本当に簡単で簡単でよく説明されています。
あなたの質問は非常に曖昧で広範であるため、ここではうまく答えることができません。
特定の実装上の問題が発生した場合は、これが適切な場所です。
ただし、質問の少なくとも一部に答えるには、次のようにします。
Facebookアプリケーションを操作する際の最も強力なツールは、GraphAPIです。
その原理は非常に単純です。ユーザーまたはアプリケーションに代わって、任意のアクションを実行できます。最初に、ユーザーと適切な権限を識別するトークンを生成する必要があります。これらのトークンは「永続的」にすることができるため、バックグラウンドタスクを実行できます。通常、これらは非常に短時間しかアクティブにならないため、ユーザーと対話しながらアクションを実行できます。トークンを生成するプロセスにはユーザーが関与するため、ユーザーは要求している特権を確認する必要があります。
何かを自動的に公開するWebサイトの場合、プライバシー設定でアプリを削除する限り、アクティブな永続トークンを1回生成する可能性があります。
基本的に、yuoは任意のWebサイトの任意のアプリケーションで動作します。制限はありません。ただし、トークンを生成する方法は2つあります。1つは追加のリクエストを含み、もう1つはクライアント側で実行されます。これは、アプリの設定で指定された1つのドメインoyuにバインドされます。
補遺：
@ArtoAle
あなたは、すべてのアプリが正確に1つのドメインに協力していることについて正しいです。ただし、有効なトークンを取得すると、グラフAPI内のどこからまたは誰がトークンを使用するかは重要ではありません。
これを少し説明させてください：
あなたがリクエストをしているので、それは意味がありません。「リクエストの出所」などはありません。もちろん、「リファラー」ヘッダー情報はありますが、自由に指定でき、このコンテキストでは使用されません。
アプリの設定で入力するドメインは、Facebookがユーザーをリダイレクトする場所のみを制限します。
なぜ？
これにより、悪意のあるユーザーがどのドメインにもWebサイトを設定できなくなり、ユーザーがアプリを承認して、アプリケーションでアクセストークンを取得できるようになります。
したがって、この設定により、ユーザーとアクセストークンは、別の不正なサイトではなく、自分のサイトにリダイレクトされます。
しかし、別の方法があります。デスクトップアプリケーションの制御フローを使用する場合、ユーザーがリダイレクトされた直後にアクセストークンを取得することはありません。アクセストークンと交換できる一時的なSESSION-TOKENを取得します。この交換はRESTAPIを介してサーバー側で行われ、アプリケーションシークレットが必要です。したがって、この時点で、トークンを取得するのはあなたであることが保証されます。
この方法は、任意のドメインで実行できます。または、ドメインがまったくないデスクトップアプリケーションの場合は実行できます。
これはfacebooドキュメントからの引用です：
セッションを変換するには、変換するセッションのコンマ区切りリストを使用して、POSTリクエストを https://graph.facebook.com/oauth/exchange_sessionsに送信します。
curl client_id = your_app_id \ -F client_secret = your_app_secret \ -F session =2.DbavCpzL6Yc_XGEI0Ip9GA__。3600.1271649600-12345,2.aBdC...\ https: //graph.facebook.com/oauth/exchange_sessions リクエストからの応答は指定されたセッションと同じ順序でのOAuthアクセストークンのJSON配列：
[{"access_token"： "..."、 "expires"：1271649600、}、...]
ただし、この方法はもう少し複雑なので必要ありません。あなたのユースケースでは、承認の中心点を使用することをお勧めします。
したがって、1つのドメインをリダイレクトURLとして指定します。このドメインは、Webサイト間で共有されます。そこで、完全に有効なアクセストークンを取得し、ユーザーを特定のプロジェクトWebサイトにシームレスにリダイレクトして、アクセストークンを渡すことができます。
このようにして、おそらくより将来性のある従来の簡単な認証フローを使用できます。
事実は残っています。アクセストークンが生成されると、任意のドメインから任意のアクションを実行できます。リクエストの送信元の「ドメイン」は文字通りないため、違いはありません（上記を参照）。
それとは別に、コメントボックスや「いいね」ボタンなどの優れたJavaScript機能を機能させたい場合は、開いているグラフタグを正しく設定する必要があります。
実装上の問題がある場合、または「ドメインエラー」と言ったように、それらをより明確に説明し、実行した手順と、可能であればエラーメッセージを含めてください。