先月7月に久々（1年ぶりくらい）にわんくまブログにエントリしました。3エントリ（3日分）です。これでやめたらまさに3日坊主になってしまいます(笑)。毎月1エントリぐらいはしないとということで、8月になったのでエントリしてみます。
既に山ほどTwitterクライアントはありますが、自分好みの機能がない場合があります。その場合は自分で作成してしまうのもよいプログラミングの練習になって面白いです。Twitter APIの勉強にもなります。私ももちろんTwitやモバツイなどの有名なツイッタークライアントにお世話になっていますが、実は一昨年ごろから自分専用の自作クライアントを作成していました。公開はしていないので好き勝手にいろいろな機能を仕込んだりできます。
以前、in_reply_to_status_idが追加されたころには@をつけなくても、リクエストにin_reply_to_status_idに実際の誰かのつぶやきのstatus_idを仕込めば相手の返信リストに発言を入れることができて驚かせるというようないたずらもできました。今は@もないと相手の返信リストに入らなくなっています。
また、タイムライン取得などAPI制限と呼ばれる1時間当たりの実行回数制限があるAPIがありますが、以前は、POSTでもタイムラインを取得できてAPIが減らさずに済むという裏技もありました。今はGETしかつかえないようです。さらに、タイムラインの取得にcountパラメータを知っていると便利です。公式サイトやcountなしの場合のタイムラインは基本的に20発言しか表示できません。countを使うと以前は800件、現在は200件ぐらい取得できます。これを使って、Javascriptのbookmarkletで「一行Twitterクライアント」「Twitterのユーザ発言を過去にさかのぼるBookmarklet」を日記のネタにしたりしました。
Twitterより4月にセキュリティの弱いBasic認証を終了するという発表がありました。
「Twitterブログ: ベーシック認証について」 http://blog.twitter.jp/2010/04/blog-post_30.html
こうした利点を備えるOAuthの普及が進んだことから、われわれはベーシック認証への対応を2010年6月30日をもって終了する予定です。このためそれ以降は、ベーシック認証を行っていたサービスが利用できなくなる可能性がありますのでご注意ください。
Basic認証は単純な認証方式で、ユーザ名・パスワードが端末のどこかに保存され、通信の度に毎回ネットワークに流されます。たしかにいろいろな不安要素があります。
クライアントが既にこれ以外の認証方式に対応していればいいのですが、Basic認証しか使っていないものは対応しなければならなくなりました。
この期限は6月の発表で延長されました。
「Twitterブログ: Twitter APIデベロッパー・コミュニティへのお知らせ (OAuthへの移行に関しての期限延長)」 http://blog.twitter.jp/2010/06/twitter-api-oauth.html
8月16日から8月31日の間、毎日APIを呼ぶ回数制限(rate limit)を毎日減らします。(1時間あたり10コールの単位で減らします。) 8月31日からはベーシック認証のAPIコールに対しては全てHTTP 403エラーを返します。
9月にはBasic認証のみだとAPIを利用できなくなってしまします。
私も自分の自分しか使用していない自作クライアントをTwitterのOAuth認証に対応させることにしました。
[Link]「OAuth - Wikipedia」 http://ja.wikipedia.org/wiki/OAuth
OAuth認証の手順は以下に仕様があります。(英語)
[Link]「OAuth Core 1.0」 http://oauth.net/core/1.0/#anchor9
実装例は以下にあります。
[Link]「Twitter API Wiki / OAuth Examples」 http://apiwiki.twitter.com/OAuth-Examples
OAuthの認証手順は大まかには「OAuth Core 1.0のページ」 の図に書いてあるとおり以下の流れです。
今回の場合、図のConsumerがTwitterクライアント、Service ProviderがTwitterです。
- クライアントがTwitterにRequest Tokenを要求する。
- TwitterがクライアントにRequest Tokenを返す。
- ユーザにAuthorizeページでクライアントアプリケーションを「許可」してもらう。
- Twitterが暗証番号を表示する。
- ユーザがクライアントに暗証番号を入力する。
- クライアントがTwitterにAccess Tokenを要求する。
- TwitterがクライアントにAccess Tokenを返す。
- クライアントにAccess TokenとAccess TokenSecretを保存する。
- 以降、クライアントはAccess Tokenを含めてAPIの各リクエストをする。
各手順では細かいパラメータがあります。
クライアントがデスクトップアプリケーションの場合、ユーザにTwitterのwebページで許可してもらって、そこで表示される暗証番号(PIN, oauth_verifier)を入力してもらわないといけません。
この部分を不要にしたxAuth認証というものがありますが、
「Twitter API Wiki / Twitter REST API Method: oauth access_token for xAuth」 http://apiwiki.twitter.com/Twitter-REST-API-Method:-oauth-access_token-for-xAuth
In order to get access to this method, you must apply by sending an email to api@twitter.com ? all other applications will receive an HTTP 401 error.
と書かれているとおりapi@twitter.comにメールを送って承認してもらわなければなりません。自分しかユーザがいないクライアントの場合にはこれをするのは気が引けます。承認されないかもしれません。
また、xAuthはユーザにとっても、クライアントにユーザ・パスワードに入力する必要があるので、端末のどこかに保存されるというBasic認証と同様の不安要素が残ってしまいます。
というわけで、結局、OAuth認証に対応させようというわけです。
長くなってしまったので、実装編（？）は別のエントリにします。