これは完全に実行可能です。Facebook でアプリにアクセス許可を付与するすべてのアクションでリダイレクトを実行する必要があることを理解して、認証構造を実装するかどうかにかかっているだけです。これには、アプリの外部でブラウザーを開くことが含まれる場合があります。または、認証のためだけに IPhone SDK を使用し、OAuth プロセスの完了後にクライアント デバイスによってサーバーに access_token が送信されるようにすることもできます。
これは、Facebook/Twitter/Google + 他の OAuth プロバイダーと一緒に独自の認証システムをセットアップしたいアプリケーションにとって非常に一般的なアプローチです。一部の Facebook ユーザーに関連付けられているネイティブ ユーザー ID を維持し、必要に応じてアクセス トークンを取得します。永続的なオフライン アクセスを取得するプロセスは、永続的なトークンから更新するトークンに変更されました。関連するすべての詳細が記載されている別のディスカッションを参照します。
Facebookトークンを保存するフィールドタイプは?
有効な access_token が取得され、永続ストレージまたはセッションに保存されると、それを使用して、クライアント側 SDK がデータのフェッチと交換に使用するのと同じエンドポイントにアクセスできます。これは通常、何らかの HTTP ライブラリで実現されます。たとえば、SDK for PHP は、認証プロセスを自動化し、アクセス資格情報をリクエスト データに埋め込むことで、ブラウザー ウィンドウ内からこのプロセスを促進するだけです。これは、endpts を標準の HTTP ライブラリ (python の urllib または HTTPlib) で使用し、新しく取得した access_token をリクエスト変数として手動で設定してグラフ API に送信することにより、サーバー側で完全にシミュレートできます。
Python ルートを使用し、クライアント側でのニーズを完全に電話で処理する場合は、 Werkzeug WSGI ライブラリのバリアントであるFlaskを検討することを強くお勧めします。このツールは、いくつかのシリアル化されたデータ (あなたの場合、おそらく FB から直接 JSON) をエコーアウトするクイック endpts をスピンアップするのに勝るものはありません。他のニーズにどのライブラリを使用するかを自由に決定できるため、デプロイされたコードベースを可能な限り小さく保つことができるため、私は Web サービス タイプの作業でこれを常に気に入っています。