[観] Twitter バックナンバー

Twitter -- Hot Topics

「Twitter API プログラミング」の韓国語翻訳版が出版されました

拙著「Twitter API プログランミング」を韓国語に翻訳した本「Twitter API 개발자 레퍼런스」(ISBN: 978-89-314-4054-6)が韓国で出版されました。

今日、私の手元に見本誌が届いたので、ぱらぱらっと見てみたところ、本の構成というか内容は拙著そのままで、日本語部分をハングルにそっくり置き換えた感じのようです。開発者向けの教科書というか参考書というか、そういう本のシリーズのうちの1つとして扱われているみたいです。

サンプルプログラムや OAuth 解説用のソースコードもそのまま載ってますし、巻末のインタビューも収録されてますので、本当に日本語をハングルに置き換えただけのように見えます。拙著が出版されてからの Twitter の新しい動向(User Stream の話とか、2010年11月のステータスIDのビット数変更の話とか)が盛り込まれているのかどうか、その辺が気になるのですが、まだそこまでじっくりチェックできていません。2010年4月以降、大きな仕様変更はないので、盛り込まれてなくても何とかなるとは思いますが。

以上、簡単ですが、報告でした。

proxy サーバー越しに Twitter の xAuth によるアクセストークン取得時の注意点

Twitter では、2010年6月末をもって、BASIC認証が使えなくなります(単に非推奨になるだけで、しばらくの間はまだ使えるという噂もありますが、あんまり当てにしない方がいいと思います)。そのため、既存のアプリケーションや、今後作成予定のアプリケーションは、OAuth もしくは xAuth をサポートする必要があります。

OAuth の方は API レベルでの仕様に忠実に実装すれば問題なく使えるのですが、xAuth に関しては、API レベルでの仕様に忠実に実装していても、その下位レイヤ、つまり http/https レベルでの実装がどうなっているか次第で、うまく認証が通らない(アクセストークンの取得ができない)ことがあります。

xAuth ではアクセストーク取得時は SSL (https) で通信することになっています。直接 Twitter のサーバーとの間で SSL 接続を確立して通信する場合は問題は起きないのですが、proxy サーバー越しに Twitter のサーバーと SSL 通信を行なう場合は、アクセストークンの取得に失敗することがあるのです。

proxyサーバー越しに SSL で通信を行なうとき(CONNECT による SSL 接続確立後)は、http リクエストヘッダの冒頭行に含まれる URL はフルパスで書くことになっています。この URL は、本来(SSL通信の場合でも) http:// で始まるものを使うことになっているのですが、世の中には https:// を使う実装も存在しています。

例えば、C# の HttpWebRequest (IEコンポーネントベースのライブラリ)では、proxyサーバー越しでの SSL 通信時は、リクエストヘッダに https:// で始まる URL を書いてアクセスを試み、失敗した場合は、http:// で始まる URL で再度アクセスを試みる、というような実装になっています。

あるいは、拙作の Twitter クライアント Chirrup で使っている自前のhttp/httpsライブラリでは、経験的に https:// でないとうまく通信できないことがわかっているサーバーに対しては https:// で、それ以外は http:// でアクセスを試みる実装になっています。

たいていのWebサーバーは、http:// でも https:// でも問題なく、相手をしてくれるのですが、一部、http:// じゃないと駄目なサーバー、逆に https:// じゃないと駄目なサーバーがあります。

Twitter の場合は、いちおう「http:// でも https:// でも問題なく、相手をしてくれる」Webサーバーを使っているようなのですが、こと xAuth によるアクセストークン取得に関しては、https:// でないといけないようです。

拙作の Twitter クライアント(としての機能を内蔵したWebブラウザ) tumblen3 では問題なくアクセストークンが取得できるのに、もう1つのクライアント Chirrup ではなぜか取得に失敗する(認証エラー)になるという問題を2010年2月に経験し、その原因を追及していった結果、「xAuth によるアクセストークン取得に関しては、https:// でないといけない」ことがわかりました。tumblen3 は C# (の HttpWebRequest) による実装のため、問題なく動作し、Chirrup は(ごく一部のサーバーを除いて) http:// でアクセスする実装だったため、失敗していたのでした。今では、Chirrup も https:// でアクセスすることで、この問題を克服しています。

参考

この辺の話は、拙著「Twitter API プログラミング」の118ページ「xAuth によるアクセストークンの取得をプロキシサーバ越しに行う場合の注意点」というコラムにも書きました。よろしければ、参考にしてください。

その他の問題

ファイヤーウォール内からインターネットにアクセスする環境では、場合によっては通信内容を監視するため、以下のような構成の proxy サーバーを採用していることがあります。このような環境の場合、その環境特有の問題で、xAuth がうまく通らない、ということがあり得ます。この場合は、その環境依存の対策(を行なう場合は、ネットワーク管理者、管理部門の許可を取ってくださいね)が必要になりますが、対策不可能かもしれません。