2012-05-14 15 views
1

私のアプリは、クライアント側でFacebook Javascript SDKの承認を使用しています。承認されたユーザーのアプリはFacebook APIからのアクセストークンを、署名入りのリクエストでfacebook cookieを使用して取り出し、codeとしてデータベースに保存します。新しいアクセストークンを読み込む必要がありますか?

すべて正常に動作していますが、私は格納されたアクセストークンを更新する必要がありますか?ユーザーがパスワードを変更し、再度サインイン/接続した場合はどうなりますか?

私が理解しているように、彼女は新しいアクセストークンを持っています。そして、アプリケーションはFacebookからそれをロードする必要があります。しかし、私は新しいトークンを確認する必要があるとき、私はどのように理解できますか?フェイスブックのクッキーで各リクエストをチェックすると、各ユーザーの1秒あたりのリクエスト数が少ないため(パスワードを変更しなかった場合のイベント)、動作しません。または、私は何か間違っているのでしょうか?

は私が意味:私は、クライアント側のユーザを認可しました

  • 私が署名したリクエストにクッキーをしました
  • 署名要求(ユーザー資格情報を検証する)、サーバー側のユーザを承認するかなり十分です
  • access tokenは、ユーザーのユーザーが私のアプリにリクエストをしたとき(いつでも署名付きリクエストからcodeが必要なため)Facebook APIを呼び出すことで取得できます。だから、私はaccess tokenを保存していないか、または既存のaccess tokenが期限切れになったときにそれをやっています。保存されている場合access token期限が切れますが、無効化されていない何
  • (私たちは署名要求を持つユーザーの要求とクッキーを持っていない意味)多分、数分後に、単にデータベースに格納され、別のスレッドで、いつでも使用することができ
  • access token facebook側で?新しいaccess tokenを取得する必要がありますが、この時点でCookieが終了しました。 databseに署名した要求から店舗codeを、そして我々は我々が無効access tokenを持っていることを発見したとき、それをロードしよう:

は現在、私は唯一の方法を参照してください。しかし、私はそれが適切な方法であり、ほとんどの場合にはそれほど役に立たないと確信しています。

答えて

3

クライアントトークンとサーバートークンがあり、クライアントは短命(数時間)であり、 60日)。

それは「Handling Invalid and Expired Access Tokens」ガイドに述べてあなたは簡単に新しいものを得ることができるので、クライアント側のトークンがあなたにあまり気にしないでください。認証を実装

デスクトップWebおよびモバイルWebアプリケーションJavascriptのSDK

はFB.getLoginStatus()を呼び出したり、ステータスを保証すると:あなたはFB.init(コール たときに真が設定されている)、次回は、ユーザーが アプリケーションに土地やFacebookにサインインしていることを意味しauthResponseオブジェクトの場合これらの呼び出しに新しく有効な アクセストークンが含まれているため、が渡されます。

この場合、暗黙的に新しいアクセストークンを生成するアプリケーション を使用するユーザーの行為です。

デスクトップWebおよびモバイル:

あなたに簡単に再生することができない、デシベルで持続サーバ側のトークンは、ユーザーが再び認証ダイアログに送信する必要がありますあなたは再び完全なサーバー側流を介してユーザ を渡す必要があり、この場合には、新鮮なアクセストークンを取得するには、サーバー側の認証フローに

を実装したWebアプリケーションは:すなわち、コードと新しいため 為替それを得ますアクセストークン。ただし、ユーザーと仮定すると、アプリケーション、 あなたはOAuthのダイアログにユーザーをリダイレクトする場合、ユーザーは ではありませんデ認可されていません

は、アプリケーションを再認可するように促され、すぐに あなたREDIRECT_URIにリダイレクトされます。これは、再認証 プロセスがユーザーにトランスペアレントに見えることを意味します。

もちろん、クライアントトークンをサーバーに送信して、それを維持することはできますが、それは短命なのでかなり無意味です。 もう1つの方法は、new endpoint to extend有効なクライアントトークンをサーバー側で使用し、それを維持することです。

「新しいトークンを取得する方法を知る方法」については、サーバー側でAPIリクエストを作成するときにレスポンスを確認し、エラーが返されたかどうかを確認してください。私が追加した最初のURL)。 トークンが期限切れになっている場合は、ユーザーに再度認証ダイアログを送信します(クライアント側に何らかのコードを戻してそこから実行することができます)。次に新しいトークンをdbに保存します。

クッキーを確認する必要はありません。バックグラウンドで使用されているCookieはチェックする必要はありませんが、何もする必要はありません。


編集

クッキーを使用しないでください、彼らはいつでもあなたを気にはなりません。あなたは何をすべき

サーバー側では、あなたは、Server-Side auth guideの指示に従ってください「コード」を取得し、トークンと交換する必要があります。 そのトークンには60日間が与えられます。

必要に応じてデータベースに保存するトークンを使用します(他のスレッドではありません)。またトークンの有効期限が切れているというエラーが戻ってくると、ユーザーを認証ダイアログページに戻すだけです。

「コード」を使用して複数のトークンを取得することはできません。 ユーザーセッション(とトークン)が無効になった場合(様々な理由で)、apiリクエストを作成しようとするとフェイスブックからエラーが返されます。

+0

クライアント側のJavascript認証とサーバー側の認証を組み合わせる方法がないということですか?私は、サーバサイドのユーザを認証するために、サーバがFacebookのクッキーを解析することが確かに十分であることを意味します。しかし、このクッキーにはアクセストークンは含まれておらず、サーバーはまだ記憶されているキャッシュされたアクセストークンが有効であるかどうかを知りません。 –

+0

クッキーに関与する必要はありません。それでSDKがあなたにそれをさせます。すべてのトークンには有効期限(アプリケーショントークンを除く)があり、トークンが有効かどうかをチェックし、トークンが有効であるかどうかを調べることができます。 js/server authについては、私が書いたように、クライアントトークンをサーバーに送ることはできますが、それを拡張しない限り、無意味です。 –

+0

私たちはさまざまなことを話しているようです。私は私の質問を更新しました。どうぞご覧ください。 –

関連する問題