#php sdk

[mirceadaniladumitrescu]

Facebook PHP SDK infinite redirect

Ever run into an infinite loop of redirections when trying to authenticate with Facebook ? There are multiple reasons for this, but the most common one is that your redirect uri does not match what Facebook expects. If by any chance you left the value empty expecting the SDK to figure it out and redirect your request back, there are a few things you need to consider:

you are behind a decent load balancer and SSL accelerator, in which case you need to initialise the Facebook class with 'trustForwarded' => true. This will trust the headers coming from the load balancer and set https properly for your uri.

you also need to make sure that your server supports $_SERVER['HTTPS']. Apache does that by default, but other servers, like nginx need additional configuration changes for this.

That's all. Here is the bit of code that ruined my night last night:

protected function getHttpHost() {

    if ($this->trustForwarded && isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {

      return $_SERVER['HTTP_X_FORWARDED_HOST'];

    }

    return $_SERVER['HTTP_HOST'];

  }

  protected function getHttpProtocol() {

    if ($this->trustForwarded && isset($_SERVER['HTTP_X_FORWARDED_PROTO'])) {

      if ($_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {

        return 'https';

      }

      return 'http';

    }

    if (isset($_SERVER['HTTPS']) &&

        ($_SERVER['HTTPS'] === 'on' || $_SERVER['HTTPS'] == 1)) {

      return 'https';

    }

    return 'http';

  }

Other than that seems that the new version of PHP-SDK 3.2.1 does not allow to get the token multiple times. At some point the sdk runs getAccessTokenFromCode() which is supposed to use the current code to get a token. Make sure you cache this token, as you cannot get another one with the same code. If you are using the Facebook JS SDK, the code is taken from the fbsr cookie and it changes with each page load, but if you are planning to use this multiple times on the same page, just cache the token. It's the most sane thing to do considering the unnecessary extra requests.

Let me know if my rambling helped in any way. 

[crocos]

Facebook PHP SDK 解体新書 第5回「JavaScript SDK と連携してる際に適切に Access Token が取得できない問題について」

こんにちは。 @sotarok です。 Facebook PHP SDK について深〜い解説をする「解体新書」シリーズ、今日はじめて書くんですがいきなり第5回から行ってみようと思います。

というわけで、表題の通り、「JavaScript SDK と連携してる際に適切に Access Token が取得できない問題について」のお話をします。

※ ちなみに執筆次点でリリースされている Facebook PHP SDK v.3.1.1 をベースとしています。

補足の前提知識、JavaScript SDK と PHP SDK の連携

Facebook PHP SDK は、JavaScript SDK と、特に何も意識せずに COOKIE を介して連携しています。具体的には、JS で FB.init() された際に生成される fbsr_xxxxx という COOKIE を PHP SDK が読み取り、その情報 (Signed Request 相当のデータが格納されています) を元に PHP SDK 上でもログインすることができるようになっています。

突然発生しはじめたエラー

Facebook ではよくあることですが、今まで動いていたコードが、APIサーバー側に施された何かによって動かなくなると言うことがあります。 で、今日出会ったのは、

$facebook->getAccessToken();

が動かない！という問題です。特に認証周り何もいじっていないのに、次のような OAuthException が発生するようになりました。

This authorization code has expired.

しかも、

人によって発生したりしなかったり

アプリによって発生したりしなかったり

という状況で、やれやれな雰囲気が出ています。わかったからこそこういうタイトルで記事を書いていますが、JavaScript SDK と連携していたせいで発生していたエラーだということに気づいたのはほとんど解決する直前でした。

このエラーは、 getAccessToken() を呼んだ際に発生していたのですが、それを発見するに至った経緯も含め、を詳しく見ていくことにします。

コールされたAPIとその結果

開発環境で再現条件を探るなかで、手順を最小限にするため、次のような画面遷移のみに絞って検証をしました。

PHP SDK の getLoginUrl() メソッドで取得できる URL にジャンプ (ご存じの通り、飛び先は Facebook の認証画面)

戻ってきたページで getAccessToken() メソッドで Access Token を取得

つまり、HTTPリクエスト的には、

うちのアプリでログイン用URLの生成

Facebookの認証画面

うちのアプリに code パラメータ付きで戻ってくる。それを元に Access Token を取得

という遷移をします。一応弊社のライブラリでは、Facebook PHP SDK がリクエスト飛ばす部分に手をいれて、

どんなリクエストが飛んで、

どんな結果が返ってきているのか、

がすべてログに出せるようになっています。このとき発生したログは、「2.」のタイミングで、

[2012-07-10 17:26:42] app.DEBUG: Facebook API[1]: https://graph.facebook.com/oauth/access_token - {"client_id":"10472078961xxxx","client_secret":"daa8a082d4db023bf1316f2e49dfxxxx","redirect_uri":"","code":"2.AQCOriuA5Anxxxxx.3600.1341910800.1-58888xxxx|1341905535|iOoQHNn-ZPesX6RsXBwUCibxxxx"} (10472078961xxxx|daa8a082d4db023bf1316f2e49dxxxxx) [] [] [2012-07-10 17:26:43] app.DEBUG: Facebook API[1] result: {"error":{"message":"This authorization code has expired.","type":"OAuthException","code":100}} [] []

というログが出ていました。このとき、Facebookからどいういうパラメータ付きで戻ってきたかというと、正常に認証が完了し、 /login/check?state=xxxxxxxxx&code=XXXXXXXXXXXXX のように、CSRFチェック用tokenであるstate (今回は詳しくは言及しません) と Access Token 取得のための code を query string に付与して戻ってきていました。 で、その画面で、/oauth/access_token に code をつけてリクエストを送ったタイミングで、OAuthException の "This authorization code has expired." が発生した、ということです。

最小の手順でこれが発生するということは、もう getAccessToken() が怪しくてしかたありません。ということで、このメソッドの中身を見ていきます。

getAccessToken() がやること

このメソッドは、

public function getAccessToken() { if ($this->accessToken !== null) { return $this->accessToken; } $this->setAccessToken($this->getApplicationAccessToken()); $user_access_token = $this->getUserAccessToken(); if ($user_access_token) { $this->setAccessToken($user_access_token); } return $this->accessToken; }

こういうメソッドで、つまり、

$this->access_token がセットされていたらそいつを返す

デフォルト値としてとりあえず Application Access Token をセットする

これは、 APP_ID と APP_SECRET をパイプ | でつないだものです

User Access Token を取得できたら、そいつをセットする

で、この中で怪しいのは、というか、/oauth/access_token にリクエストを飛ばすのは、明らかに getUserAccessToken() です。

getUserAccessToken() がやること

メソッドは、次のようになっています。

protected function getUserAccessToken() { // first, consider a signed request if it's supplied. // if there is a signed request, then it alone determines // the access token. $signed_request = $this->getSignedRequest(); if ($signed_request) { // apps.facebook.com hands the access_token in the signed_request if (array_key_exists('oauth_token', $signed_request)) { $access_token = $signed_request['oauth_token']; $this->setPersistentData('access_token', $access_token); return $access_token; } // the JS SDK puts a code in with the redirect_uri of '' if (array_key_exists('code', $signed_request)) { $code = $signed_request['code']; $access_token = $this->getAccessTokenFromCode($code, ''); if ($access_token) { $this->setPersistentData('code', $code); $this->setPersistentData('access_token', $access_token); return $access_token; } } // signed request states there's no access token, so anything // stored should be cleared. $this->clearAllPersistentData(); return false; // respect the signed request's data, even // if there's an authorization code or something else } $code = $this->getCode(); if ($code && $code != $this->getPersistentData('code')) { $access_token = $this->getAccessTokenFromCode($code); if ($access_token) { $this->setPersistentData('code', $code); $this->setPersistentData('access_token', $access_token); return $access_token; } // code was bogus, so everything based on it should be invalidated. $this->clearAllPersistentData(); return false; } // as a fallback, just return whatever is in the persistent // store, knowing nothing explicit (signed request, authorization // code, etc.) was present to shadow it (or we saw a code in $_REQUEST, // but it's the same as what's in the persistent store) return $this->getPersistentData('access_token'); }

コード中のコメントが解説してくれていますが、今回画面遷移の場合とあわせて解説すると、

Signed Request があったらそれを使って access token をとりにいくよ

Signed Request は、Facebook App Canvas や Page App の Canvas で開いたとき、iframe ごしにくるリクエストなので、今回のような、App Canvas 内ではない場所で利用しているアプリでは基本的に関係ない（はずである）

そうじゃなかったら code を使って、Access Token を取得しにいくよ

今回の場合、Facebookの認証画面から code 付きで戻ってくるので、こっちでリクエストが飛ぶはずである

Signed Request もなくて、code もなかったら、一応最後に、Persistent Data (セッションです) に入ってる access token を返すよ

今回はここにはこないはず

という処理になっています。

エラーメッセージが「This authorization code has expired.」なので、/oauth/access_token に対して Access Token の発行のリクエストを飛ばすタイミングでつけている code が expire してるぜってことっぽいので、まず、どんな code を使ってるのかを確認します。 こういう場合は当然必殺の「var_dump()とexit」なので、次のように、code を出力してみます。

$code = $this->getCode(); var_dump($code);exit;

この状態で、同じ遷移をテストすると ...

お ... code が出力されない！

あれ、code のところに来てない？ってことは signed_request に何か入ってるんだっけ？という疑いのもと、以下のようにデバッグコードを仕込むと ...

$signed_request = $this->getSignedRequest(); error_log(var_export($signed_request, true));

ログには ...

[10-Jul-2012 08:31:36 UTC] array ( 'algorithm' => 'HMAC-SHA256', 'code' => '2.AQCOriuA5Anxxxxx.3600.1341910800.1-58888xxxx|1341905535|iOoQHNn-ZPesX6RsXBwUCibxxxx', 'issued_at' => '1341909094', 'user_id' => '58888xxxx', )

見事に、入っていました。このときハッとしたのですが、これは、JavaScript SDK によって入れられたものです。 getSignedRequest() の中身は今回は紹介しませんが、大まかにいうと、POST リクエストで Signed Request のデータが渡されていればそれを、それがなければ COOKIE から復元という手順で Signed Request を返してきているからです。

つまり、認証手順で Facebook から code が返されているにもかかわらず、それを使わず、それより古くにJSで設定された Signed Request 内の code を使って access token をとりにいくから expire してました 、という話でした！ これを無視して、クエリで渡された code を使って認証すれば、正常に Access Token を取得することができました。

人によって・アプリによって発生したりしなかったりしたのは、その人の COOKIE にそのアプリのデータが残っていたかどうかによるからですね。

問題の概要

今日突然起こるようになったことに対する想像

今までは、code に対する expire のチェックをしていなかったのではないか

つまり、JavaScript SDK によって COOKIE につっこまれた古い code を元に Access Token の発行ができた

これじゃまずいよね、とおもった中の人がついに expire のチェックをするようになった

しかし、このように、

query string などに code を受け取っていても、Signed Request があったらそれを最優先で認証に使う

Signed Request は JavaScript SDK によってセットされる可能性がある

code は expire する

という仕様になっているのであれば、「Signed Request を元に Access Token を取りに行く」というのは、必要だとして、正規の認証経路で戻ってきて code が query string に渡されていて、かつ、JavaScript SDK によって COOKIE に Signed Request がセットされている、という場合が存在するので、 Signed Request を元に access token を取得しにいって、だめなら query string に渡された code を元に Access Token をとりにいくという fallback 処理があるべきなのではないか、という感じです。 Signed Request が Signed Request によるものなのか、JavaScript SDKによるものなのか区別されていないので。

ところで、この問題は、以下の条件下で発生します。

どこかでそのアプリが FB.init されたことがあり、その時点から一定時間が経過している (expire する程度には)

getLoginUrl() がコールされて Facebook にジャンプする前に FB.init() される場所が無く、COOKIE も生きている

この条件を満たさない場合は回避できるでしょう。(たとえば、getLoginUrl() のURLにジャンプする直前の画面で JS で FB.init() されているとか)

ちなみに、Authorization Request の code に関しては、OAuth 2.0 の最新の proposal には、以下のような記述があります。

4.1.2. Authorization Response

code REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once.

code の lifetime は最大でも 10 分が望ましい

client は、authorization code は1回しかつかっちゃだめ

このあたりを、ちゃんとチェックするようになったんですかね(いままでやってなかった...?)。

対策

対策としては、

FB.init() する画面を挟む

認証のリクエスト前に COOKIE 消す

getUserAccessToken() に Signed Request → code の fallback 処理を入れる

といったものが考えられますが、今回はアプリの画面遷移の特性上、COOKIE 消すことにしました。というか、destroySession() メソッドを呼ぶことにします。

本来、COOKIE が PHP にとって Persistent Data に近い存在として扱われるので、clearAllPersistentData() のタイミングで COOKIE を消すべきなんじゃないかなーと思っていますが、後日このへんのアイデアをまとめて SDK の修正案を Pull Request でもしてみようと思います。 ブログ書いてたら疲れたのでまた後日 ...

まとめ

JS SDK と連携してると、COOKIE で意外とハマる

突然エラーになったりする

まぁだいたいコードに書いてあるので1つずつ追えば原因はわかる

では、第1〜4回と6回以降もご期待ください。 次回は「JS SDK と連携している際にユーザの切り替わりを検知できない問題について」をお届けする予定です。