Big Sky :: TwitterのBasic認証廃止は約半分のデスクトップクライアントを殺した。

さて、TwitterがBasic認証を廃止して1ヶ月が経とうとしています。
皆さんクライアントをOAuth対応したり、乗り換えたりしたでしょうか？
今までBasic認証で動いていた、ちょっとした捨てコード、どうなってるでしょうか？
Twitterが始まった当初、gtktwitterというデスクトップGUIで動くTwitterクライアントを作りました。まぁ作りはそれ程優れた物じゃなくて、RTなんか無い頃でfriends_timelineが見れて、発言出来て、@によるリプライが出来る程度の物でした。
ただ純粋なC言語だけでGTKおよびcurlを使ったクライアントという事もあり、一部のgeekからは人気があったみたいです。
さてこのgtktwitterを今回、Basic認証が消え去った現状でも動くようにしてあげようと思い、今回改造を始めた訳です。
まず大きな壁にぶち当たりました。

Twitterクライアントに「twitter」という文字を含められなくなった

今まで作った物をどうしてくれるの？とも思いましたが、まぁそれはTwitterのやり方でもあるので従わなくてはなりません。「gtktwitter」を「gtktweeter」とリネームする事にしました。簡単なお仕事です。
ただし今までgtktwitterとして検索エンジンで引っかかっていた物が既に使い物にならない物になるのは寂しいですが。

デスクトップで認証出来る仕組みがxAuthしかない

Twitterがそうしろと言うならば従わないといけないのです。以前mixi APIがWSSEを採用した時も「AtomPP/WSSEなんかやめちゃえ...」と言ったりもしましたが、Twitterやりたいなら従うしかないのです。

ここまでは順調だと思ってました。
pythonでxAuthを使うサンプル書いたのも、これの布石だったりします。
あの時はCOMSUMER_KEYやCONSUMER_SECRETはクライアントのソースコードに埋め込める物と思ってたんです。

だがしかし、実際にはCONSUMER_KEYやCONSUMER_SECRETをソースコードに埋め込むという事は、APIハイジャックされる可能性がある事を意味しています。
確かにアプリケーション名として、オープンソースで公開されているアプリケーションのCONSUMER_KEY/CONSUMER_SECRETを使い、連投しオフィシャルからbanさせるなんて事も可能です。
じゃぁxAuth/OAuthしか認証方法が無い現状のTwitterで、オープンソースアプリケーションのソースコードに何を持って識別IDを格納出来るのか。

オフィシャルサポートに聞いてみました。以下その会話

mattn:

I'm author of gtktweeter that is GUI application working on unix and windows. I want to use xauth. please

こんにちわ。unixとwindowsで動くGUIアプリケーション"gtktweeter"の作者です。xauthを使いたいです。お願いします。

Twitter Support:

Thank you for your interest in xAuth. As your code is publicly available, your application's keys are posted publicly and external parties could hijack your API access. This presents an abuse risk, and you can understand our concern. Before we can proceed with granting xAuth access, you must remove the keys from your public source. Developers that want to use your code will have to register their own Twitter application and apply for it to have xAuth as well. Once you have made this change, please let us know and include a link to a screenshot of your application in action on either platform. Thanks

xAuthに興味を示してくれてありがとう。君のコードは公開状態なので、アプリケーションのキーが公に開示されてしまっている。部外者がAPIへのアクセスを乗っ取ることが出来てしまう。これは悪用乱用を招きかねないと懸念しており、あなたもそれを理解頂けると思います。私達がxAuthアクセスへの許可を与える前に、公開されておられるソースからキーを削除すべきです。あなたのコードを使う開発者は自らのTwitterアプリケーションを登録する必要がありますし、その上でそのアプリケーションに対してもxAuthの申請を行う必要があるのです。この変更を終えた後に、各プラットフォーム上でアプリケーションが動作しているスクリーンショットへのリンクを含めて知らせて下さい。ありがとうありがとう。

私は目を疑った。ただでさえこの返事を貰うまでに2日半掛かったというのに、このアプリケーションを使いたいユーザが、いちいちアプリケーション登録をし、そのIDをソースコードに埋め込む、もしくはアプリケーション上で設定し、そのCONSUMER_KEY/CONSUMER_SECRETをtwitter supportに連絡し、xAuthに許可が下りて初めてそのアプリケーションを使える様になる。
なんだそれ。

私は続けて質問した。そう、半分キレながら。

mattn:

Hi. What the best way to contain the key or sign into my application?

こんにちわ。アプリケーションにキーやサインを含める一番いい方法ってなんなの？

ちなみに、twitter supportにチケットを登録する際に「Do you feel」という項目があるのだけど、あえて私はこう書いた。

この件に関してまともな回答が得られていないのでtoo badだ

この質問に対しての返事も2日かかった。イライラする。

Twitter Support:

We recommend that you do not distribute the keys with your source at all. If you want to provide a compiled binary of your application to download, this may of course contain the keys necessary to function. Let me know how you would like to proceed. Thank

キーを含む全てのソースを公開しない事を、私達は推奨しています。もしコンパイルされたバイナリのアプリケーションをダウンロードとして提供するならば、動作の為に必要なキーが含まれているのかもしれません。どの様にされたいか教えてください。ありがとうありがとう。

やっぱり...

TwitterのxAuthって全然だめじゃん。使えないじゃん。バイナリになったとしてもスニファで確認すればCONSUMER_KEYくらい読み取れるよ。しかもx_auth_passwordなんか生だし。
まさかこんなレベルの運用を考えていたとは思ってなかった。

半分あきらめながら、以下の(イヤミを含んだ)文面を残した

mattn:
Open source.
I want to hear the best way that is possible to ...
* working at all
* publish source code

BTW) I believe that twitter revoke basic auth killed 50% of desktop application posting to twitter.
Best Regards, Thanks.

オープンソースだ。
私は以下を満たす一番の方法を聞きたいんだ。
* 全てで動作する
* ソースコードが公開されている

ところで、Basic認証を廃止した事でTwitterはポスト出来てるアプリケーションの50%を殺したんだと、私は信じているよ。
よろしく。ありがとう。

ちなみに、xAuthを使わずOAuthを使った方法もなくはない。この方法はrequest tokenを要求し、そのrequest token secretを元にaccess tokenを取得する。そのaccess token secretを持ってTwitter APIにアクセスする物。ただしaccess tokenを得る際にはブラウザで許可する必要があり、かつブラウザに表示された数桁の番号をアプリケーション側に知らせてあげなければならない。
ブラウザがどの製品かも分からないし、画面に何が表示されているかなんてアプリケーションは知る術もない。完全手作業でこのPINと呼ばれるコードをコピペするしか無いのだ。
その点、Flickr認証はこのPINを同等(flobと呼ばれる)をAPI経由で貰い、アクセス許可時に引き渡すという方式を取っている為、ユーザは初めての起動時に立ち上がったブラウザで「許可」とすれば良いだけなのである。ちなみに「非許可」とした場合の動作はTwitterもFlickrも対して変わらない。
本当にこれで良かったのか？Twitter。Basic Auth over SSLだけでも残しておいた方が良かったんじゃないの？とか思ってしまう。クライアントの認証にHMAC-SHA1やSSLの対応が必須で、ブラウザ起動の仕組みが必要で、設定ファイルに保存する項目もCONSUMER_KEY/CONSUMER_SECRET/ACCESS_TOKEN/ACCESS_TOKEN_SECRETと4つ増えた。いままで気軽にPerlやPython、Rubyでスクリプトを書いてた様な事は出来ないのだ。
APIで開発者を引き込んだTwitterにとって、この損害は小さくないと思っている。

ちなみに、この件でついカッっとなって一気にブラウザ起動を含めたOAuthのコードを書いた。
何も反省していない。