ハブろぐ - havelog.ayumusato.com

OAuth

OpenIDが、あなたは本人ですか？ねぇほんと？ねぇ？的な身元証明の技術であるのに対して、OAuthはこの人に合い鍵渡していい？ねぇ？ほんとにいいの？的な私財へのアクセス許可の技術です。

現在、Twitterの他にもYahooやGoogleのAPIもOAuth認証に対応しています。FlickrもOAuthのベースになってるような認証だった気がするけど、今はどうなんでしょうね。

とりあえずベーシック認証よりは、よっぽどセキュアというわけですが、詳しいメリットや成り立ちなどは、下の参考URLでもご覧くださいまし。

参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT

そのプロセス

コンシューマー登録

アパートの管理人（サービスプロバイダ ex.Twitter）に、合い鍵収集業者（コンシューマー）として登録し、業者ID ( コンシューマーキーとコンシューマーシークレット ) を得ます。

リクエストトークンの請求

アパートの住人（ユーザー ex.Twitterユーザー）に、合い鍵くれとリクエストを送ります。その際、業者IDをユーザーに渡して、OKなら業者IDを管理人に渡してくれ、と頼みます。

ユーザーの認否

ユーザーは管理人のとこに行って、この業者に合い鍵を渡すかどうかを判断します。（Twitterとの連携サービスとかをやると、良く出てくるアレです。許可・不許可の。）

リクエストトークンの発行

ユーザーがOKを出してくれると、合い鍵業者は、管理人に合い鍵を請求するための委任状（リクエストトークン）をもらえます。

アクセストークンの入手

委任状を手に入れた合い鍵業者は、それを携えて管理人に、そのユーザーの合い鍵（アクセストークン）をもらいに行って、それを受け取ります。

合い鍵が変わったら？

合い鍵はたまに変わってしまうかもしれません。そのとき、合い鍵業者は委任状と前の鍵を持って、もう一度管理人に会いに行きます。委任状が今でも有効なら、新しい合い鍵を受け取れます。すでに無効なら、それは住人が、あなたとの縁を切ったということです。

逆にわかりづらい？

抽象化したら逆に分かりづらい気がする。そうでもないか？まあ、そんな感じでトカゲのしっぽを切れる程度の便利認証でござる。一晩だけの関係とかでもいいわけですよ。合い鍵業者とか訳の分からないことを言わずに、夜這い業者と訳した方が良かったか。

前エントリーで述べたような、HTTPリクエストの実装よりは、よっぽどハマりポイントはありません。仕様に従って作れば一通り問題ありませんでした。OAuthで重要なのは、その意義（使い所）とプロセスを理解することです。

RFC3986の形式でちゃんとエンコードしないとダメとか、そういうのはありますが、コンシューマー側を作る分には、そこまで大変ではありません。サービスプロバイダー側を実装するのは結構面倒くさそうな...。

「OAuthについて（OpenIDとは違うのだよ）」の続きを読む

Twitter API つーか OAuthと格闘

Twitter APIと遊ぶ機会があったので、もそもそと調べたり書いたりしてみました。OAuth部分の処理を書くのに少し時間がかかったり。既存品を使っても良かったのですが「その場の環境で動けば正義」というわけにもいかないので、処理を自分の制御下におくべく、OAuth部分の実装もゼロから書いてみました。

参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT

そんときの調べごとをスピンアウト的にメモ

TwitterではOAuthでの認証を推奨？

むしろ、Basic認証はそのうち非推奨＆サポートしなくなるみたいですね。OAuthのほうがセキュアな気もしますけど、スパムにあっさり引っかかる人間の不注意がなくなるまではBasic認証のほうがセキュアじゃないんすか疑惑。

参考：Twitter APIのBASIC認証は2010年6月に「廃止予定」 - 頭ん中

APIの制限が150回ではない？

APIの回数制限がネックになるだろうなー、って思いましてAPIを叩ける回数について調べていました。したらば、公称の150回を超える回数で、回数制限対象のタイムライン系API( statuses/home_timeline.format, statuses/friends_timeline.format )を叩いていたら、150回を超えても一過性のタイムアウトを除いてちゃんと応答が返ってきている謎。

account/rate_limit_status という、現在の制限状態（残り回数とか制限がリセットされる時間とか）を教えてくれるAPIも並列で叩いてみたところ数字の推移が明らかにおかしいのです。

んで。

httpリクエストしてからレスポンスのヘッダーをとってみたら以下のような不思議な記述（抜粋）が。

string 'X-RateLimit-Limit: 450'
string 'X-RateLimit-Remaining: 306'

そしてその瞬間に account/rate_limit_status い問い合わせたところ

object(stdClass)[15]
  public 'reset_time' => string 'Tue Jan 12 12:23:27 +0000 2010'
  public 'remaining_hits' => int 102
  public 'hourly_limit' => int 150
  public 'reset_time_in_seconds' => int 1263299007

150回を超えてAPIを叩いてもちゃんと反応してくれたという事実を加味すると、どうも今の制限回数は公称値の3倍である450回に設定されているようです。remainingの値も、account/rate_limit_statusの値 *3 = http_request_headerの値 で安定しているので裏付けとなっているでしょう。

補足的に下の記事も、自分の仮説を支持してくれているようなので、ひとまず450回の制限を軸に考えていきます。もちろん、途中で150回に戻る可能性も考えなければいけませんが。

参考：Twitter API の Rate Limit が一部緩和？ - trial and error

おまけ＠TwitterとOAuth用のphpをかいたので

業務的にはきっと、a-blog cmsの中の組み込みシステムとして吸収されてしまうので、まだ独立性を保っているうちにコア部分だけ単品ファイルにして用意してみます。もう処理は書けてるので、サンプルファイル作ったら公開してみますね。

今度、ソレを使ってa-blog cmsでつくるTwitter BOTの作り方でも書いてみましょうか。もっと実用的にTwitter連携のGETモジュールでも書けたらそれでいいかな。

おまけ2＠a-blog cms でつくる Twitter BOT

今使っているロリポとかcron（指定プログラムを指定スケジュールで実行するヤツ）がないので、GETモジュールとしてBOTプログラムを起動させたらいいんじゃないかな、と。

検索エンジンのクローラーがアクセスしてくれれば、最低限の回数ぐらいは起動してくれるはず。逆にアクセス過多な場合でも、キャッシュの残存時間を調整すればいいんじゃないかしら。