Big Sky

vimキチの皆さんこんばんわ。今日もvimscript書いてますか？

今日はGoogle TasksのAPIが公開されたので、Google Tasksをvimから操作出来るvimscriptを書いてみました。
今回はoauth2で、client認証方式を取りました。Twitterの様な認証方式になります。
いつものごとく、bundleディレクトリに放り込んで

:GoogleTasks

と実行するとブラウザが起動して

という画面が出るので、テキストボックスの中身をコピーしてvim上の

CODE:

という部分に張り付けます。
すると

こんな風に一覧が表示され(初めて使う人は空っぽです)、メニューのキーをタイプします。
後は画面操作に従えば、登録・更新・削除・参照が出来ます。またeをタイプするとvim上で編集でき、":w"で書き込めます。
なお、タスク期限やタスク完了フラグの更新はまだ出来てません。とりあえず動いたよ！って所です。
動作にはwebapi-vimの最新版が必要です。
よかったら遊んでみて下さい。

mattn/webapi-vim - GitHub

Vim Interface to Web API

https://github.com/mattn/webapi-vim

mattn/googletasks-vim - GitHub

This is vimscript for googletasks

https://github.com/mattn/googletasks-vim

PerlのGrowlライブラリって色々ある訳ですが、誰かが書いたGrowlするアプリのコードを実行しようとした際にWindowsやLinuxで動かないと少し悲しくなります。
そこでGrowl::Anyってのがあればいいんじゃね？って事で書いてみました。
Mac::Growl、notify-send、Desktop::Notify、Net::GrowlClient、Growl::GNTPのどれかがインストールされていれば使えます。

mattn's p5-Growl-Any at master - GitHub

perl module that provide any growl application

http://github.com/mattn/p5-Growl-Any

今日はこれを使って、twitterのhome_timelineをGrowlするスクリプトを書いてみました。

#!perl

use strict;
use warnings;
use Config::Pit;
use Encode;
use Growl::Any;
use Net::Twitter::Lite;

my $config = pit_get("twitter-growler");
unless ( $config->{access_token_secret} ) {
    $config = pit_get(
        "twitter-growler",
        require => {
            consumer_key    => "YOUR_CONSUMER-KEY",
            consumer_secret => "YOUR-CONSUMER-SECRET",
        }
    );
    my $nt = Net::Twitter::Lite->new( %{$config} );
    $| = 1;
    print "Authorize this app at:\n ", $nt->get_authorization_url,
      "\nAnd enter the PIN: ";
    my $pin = <STDIN>;
    chomp $pin;
    my ( $access_token, $access_token_secret, $user_id, $screen_name ) =
      $nt->request_access_token( verifier => $pin );
    $config->{access_token}        = $access_token;
    $config->{access_token_secret} = $access_token_secret;
    pit_set( "twitter-growler", data => $config );
    exit;
}

my $nt = Net::Twitter::Lite->new( %{$config} );
$nt->access_token( $config->{access_token} );
$nt->access_token_secret( $config->{access_token_secret} );

my $growl = Growl::Any->new();
$growl->register( "Growl/Twitter", ["tweet"] );

my $last_id = undef;
while (1) {
    my @sl;
    if ($last_id) {
        @sl = $nt->friends_timeline( { count => 200, since_id => $last_id } );
    }
    else {
        @sl = $nt->friends_timeline( { count => 5 } );
    }
    for my $s ( @{ $sl[0] } ) {
        $last_id = $s->{id} unless $last_id;
        $growl->notify(
            "tweet",
            encode_utf8( $s->{user}{screen_name} ),
            encode_utf8( $s->{text} ),
            $s->{user}{profile_image_url},
        );
        sleep(4);
    }
}

上に書いたモジュールのどれかが入っていれば(notify-sendはコマンド)、MacでもLinuxでもWindowsでも動くはずです。

なお、実は現在Growl::Anyのパラメータをutf8フラグ付きにしようかどうか迷っているので、もしかするとその修正を入れた後にこのスクリプトを動かすと文字化けしてしまうかもしれませんので注意です。

今後ネットに転がっていたスクリプトを何も修正せずにGrowlする事が出来る様になれば、素敵な事だなと思います。

ちなみに上記のスクリプトですが、初回に実行するとconsumer_key/consumer_secretを聞かれます。ブラウザでPINを貰って入力するとConfig::Pitで設定を保存して終了するので、再度起動すると動き出します。
streamなAPIでもやってみたのですが、更新が多くGrowlの表示数が激しすぎたので一定間隔で取得する様にしてあります。お好みで修正してみて下さい。

以前まではreadonlyなAPIでしたが、先日見たら更新出来る様になってた。

Google Buzz API - Google Code

Share Buzz updates ^New!

Full read/write support with:

• Activity Streams
• AtomPub
• OAuth
• PubSubHubbub
• JSON

http://code.google.com/intl/ja/apis/buzz/

これはいかん！とばかりにvimscriptから更新してみた。

今回の対応で、vim-oauth(現在webapi-vimに取り込まれました)に幾らか修正をしました。

mattn's webapi-vim at master - GitHub

webapi-vim: vim interface to Web API

http://github.com/mattn/webapi-vim

以下、使用したスクリプト。

set rtp+=webapi-vim

let request_token_url = "https://www.google.com/accounts/OAuthGetRequestToken"
let access_token_url = "https://www.google.com/accounts/OAuthGetAccessToken"
let auth_url = "https://www.google.com/buzz/api/auth/OAuthAuthorizeToken"
let post_url = "https://www.googleapis.com/buzz/v1/activities/@me/@self"

let consumer_key = $CONSUMER_KEY
let consumer_secret = $CONSUMER_SECRET
let domain = $CONSUMER_DOMAIN
let callback = $CONSUMER_CALLBACK

let [request_token, request_token_secret] = oauth#requestToken(request_token_url, consumer_key, consumer_secret, {"scope": "https://www.googleapis.com/auth/buzz", "oauth_callback": callback})
if has("win32") || has("win64")
  exe "!start rundll32 url.dll,FileProtocolHandler ".auth_url."?oauth_token=".request_token."&domain=".domain."&scope=https://www.googleapis.com/auth/buzz"
else
  call system("xdg-open '".auth_url."?oauth_token=".request_token."'")
endif
let verifier = input("PIN:")
let [access_token, access_token_secret] = oauth#accessToken(access_token_url, consumer_key, consumer_secret, request_token, request_token_secret, {"oauth_verifier": verifier})
echo access_token
echo access_token_secret
let data = ''
\.'<entry xmlns:activity="http://activitystrea.ms/spec/1.0/"'
\.' xmlns:poco="http://portablecontacts.net/ns/1.0"'
\.' xmlns:georss="http://www.georss.org/georss"'
\.' xmlns:buzz="http://schemas.google.com/buzz/2010">'
\.'  <activity:object>'
\.'    <activity:object-type>http://activitystrea.ms/schema/1.0/note</activity:object-type>'
\.'    <content>Bzz! Bzz!</content>'
\.'  </activity:object>'
\.'</entry>'
let ret = oauth#post(post_url, consumer_key, consumer_secret, access_token, access_token_secret, {}, data, {"Content-Type": "application/atom+xml", "GData-Version": "2.0"})
echo ret

Atom APIなのでXMLでポストします。なお、今回GoogleのOAuthを使ったのですが、GoogleのOAuthってドメイン持ってないと使えないんですね。
私はここのサイトを使いましたが、Google App EngineでもOKです。

まずココでドメインを登録します。実はこのドメイン名がconsumer_keyとなります。ドメインを登録するとconsumer_secretが貰えます。
またコールバック先のURLが必要になります。通常登録したドメイン上でもよいのですが、別のサイトでも構わない様です。さらにGoogle OAuthではリクエストトークンを取得する際、およびベリファイアを貰う際にscopeパラメータが必要です。個々のGoogleサービスによって異なりますので、ココの一覧を参照して設定して下さい。なお、Google Buzzについてはリストアップされていませんが、色々探して見つけました。
さて次にアクセストークンを取得するのですが、ここで気をつけないとハマる問題がありあます。

Authentication in the Google Data Protocol - Google Data Protocol - Google Code

https://www.google.com/accounts/OAuthAuthorizeToken, referencing the request token and including the oauth_callback parameter. Google may prompt the user to log into their Google Account. Once authenticated with Google, the user chooses to share their data.

http://code.google.com/intl/ja/apis/gdata/docs/auth/overview.html

Googleのドキュメント通りでは成功しません。実は、このアクセストークン要求先は各サービスによって異なります。ここにアクセスしてもアクセストークン、アクセストークンシークレットは貰えるのですが、これを使ってアクセスしても401が返ります。Google Buzzであれば実際はGoogle Buzz専用の「https://www.google.com/buzz/api/auth/OAuthAuthorizeToken」にアクセスしなければなりません。こちらにはBuzzに対する許可設定画面も出てきます。

ここまでくればあとはAtomでXMLを送ればちゃんとBuzzってくれます。

ちなみにココが証拠ポスト。

追記
ちなみに日本語もOKでした。

ようやくTwitterのやりたい事が分かった気がする。

数日前、TwitterのxAuth/OAuthの扱いについての記事を書いた。
レスポンスの悪さや開発者に足を向けているとも思える対応に、イヤミたっぷりの文面を残したのだが...

mattn:

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

そのお返事が来ました。が、いきなり出口を塞がれてしまいました。

Twitter Support:

Hi,

Again, we ask that you do not distribute your application's keys and secrets with its source. We are happy to review your application for xAuth once you provide the requested information about it (such as an overview of its functionality and a screenshot of it in action on a Unix-based system or Windows). If xAuth is granted, it will only apply to your application keys and developers who want to compile your source will need to register their own application, apply for it to have xAuth as well, and plug their own keys into the source.

I apologize for the inconvenience that this causes. Please let me know how you would like to proceed.

Thanks

こんにちわ

繰り返しますが、アプリケーションの key および secret はソースで配布しない様、私達はお願いしておきます。 お願いしおりますアプリケーションについての情報(UNIX ベースのシステムもしくは Windows での動作スクリーンショット、および機能概要など)を提供頂いた後に、貴方のアプリケーションについて xAuth の審査をするのが楽しみです。 xAuth が権限付与される場合、それは貴方のアプリケーションキーに対してのみ適用され、貴方のソースをコンパイルしたい開発者は各々のアプリケーションを登録し、その上で xAuth を使える様に反映、そして自信のキーをソースに差し込む事になります。

これに起因するご不便をお詫び致します。どの様にされたいか教えて下さい。

ありがとうありがとう

やっぱりオフィシャルの意向としてはCONSUMER_KEYとCONSUMER_SECRETは公開するなというのが指針らしい。
それではという事でまとめて質問してみた。

mattn:

I have few question.

1. How dangerous publishing the key can be possible?
  If I put the key in the source code, what can be happen?
2. How worse is the hyjack as your said?
  Juggle of timeline of users of my application?
  Speaking ill of my application?
  Spam?
3. How many times we get approval to xAuth?
  I got replies of this issue for 1 or 2 days.
  user of my application will also looking for?

I'm finding the best way or best solution of following problem.

1. All users can use my application immediately.
2. The source code is open source completely.
3. Easy to use, no using browser, no copy and paste of pin code.

Do you have any idea?

I created UI. maybe possible to compile on unix.
screenshot is here:
  http://mattn.tumblr.com/post/1090305624/gtktweeter-on-win32-oauth

Currently, I pushed source code to repository without key.

Thanks. Thanks.

幾らか質問があります。

1. キーを公開するという事はどんな危険がありえるのか？
  ソースコードにキーを置く場合、何が起き得るのか？
2. 貴方の仰るハイジャックはどんなに悪い物か？
  私のアプリケーションを使うユーザのタイムラインを改ざん？
  私のアプリケーションに対する中傷？
  肉詰め？
3. xAuth の許可を得るのにどれだけ時間が掛かるのか？
  私のこの件の返事を貰うのに1日もしくは2日掛かっている。
  私のアプリケーションの使用者も待たされるだろうか？

私は以下の問題を解決し得る一番の解決や方法を探している。

1. 全てのユーザが即座に私のアプリケーションを使う事が出来る。
2. ソースコードは完全にオープンソースである。
3. 簡単に使える。ブラウザは使わない。PINコードをコピペしない。

何かアイデアはありますか？

UIを作りました。おそらくUNIXでコンパイル出来ます。
スクリーンショットはこちら:
  http://mattn.tumblr.com/post/1090305624/gtktweeter-on-win32-oauth

現在、私はキーを含まずにリポジトリへソースをプッシュしました。

ありがとうありがとう

問題視してくれたのか、1日以内に返事来た。

Twitter Support:

Hi Yasuhiro,
To answer your first two questions, if your application keys are public, your application may be compromised and have unintended API calls executed on its behalf. With xAuth, this also means that a compromised application can solicit usernames and passwords and take actions on their behalf that they may not intend. One of our API engineers Raffi Krikorian recently wrote about this, and to quote from his post:

Distributing an application with secrets built into it is equivalent to distributing the secrets themselves. I don't believe that there yet exists a viable platform to store secrets in widely distributed software in such a way that they cannot be eventually extracted.
...
This client identifier can never be the sole security mechanism on a platform. Instead, it is only one part of a puzzle used to maintain security on the network. What this does not mean, is that Twitter will allow applications to distribute their keys in the open. Instead, what the Platform team is trying to create is an ecosystem where getting a new key (in Twitter's case from dev.twitter.com) is significantly easier than re-using a key from another application.

You may read the rest at http://mehack.com/oauth-and-the-twitter-api .

As for your particular application, if you offer a compiled binary with its consumer key and secret made as inaccessible as possible, this should satisfy your first and third qualifications. I have granted your application, client ID 80630, xAuth access. Note that if its keys are compromised, they may be reset and your application's xAuth access may be expired for security reasons. Let me know if you have any other questions.

Thanks

こんにちわヤスヒーロ
最初の２つの質問について...もしアプリケーションキーを公開する場合、貴方のアプ リケーションが侵害される可能性があり、意図しないAPI呼び出しを肩代わりする事になります。 xAuth では、この侵害されたアプリケーションがユーザ名とパスワードを求め、意図しないであろう肩代わりのアクションを実行する事も出来てしまうのです。
我々の API エンジニアの一人である、Raffi Krikorian は最近これについて記しており、彼の記事から引用すると:

広く知られた配布ソフトウェアの中において、非公開情報が結果として抽出されない という手法で、それを格納出来る実用的なプラットフォームが存在するだなんて未だ に信じる事が出来ない。
...
このクライアント識別子は、プラットホーム上の唯一のセキュリティー対策にはなり得ません。 それどころか、ネットワークでセキュリティを維持するのに使用されるパズルの一部にすぎません。 これが意図していないのは、各々のキーをオープンに配布するアプリケーションをTwitterは許す事になるであろう、という事です。 代わりに、Platformチームが作成しようとしているのは、他のアプリケーションからキーを再利用するよりも、極めて簡単に新しいキー(Twitterの場合dev.twitter.comから)を入手する為の「エコシステム」です。

この残りはここで読む事が出来ます: http://mehack.com/oauth-and-the-twitter-api

貴方特定のアプリケーションとして、出来るだけアクセスし難い形にした consumer key と consumer secret を含んだ、コンパイル済みバイナリを計画しているのであれば、まず貴方自信と、第三の資格者を満足させる事が出来るでしょう。
我々は貴方のアプリケーションに xAuth アクセスの許可を与えました。クライアントIDは 80630 です。 キーが侵害され、キーをリセットした場合、セキュリティを理由に貴方のアプリケーションの xAuth アクセスは停止させられるでしょう。
何か他の質問があれば、教えて下さい。

ありがとうありがとう

んー...。要するにユーザIDとパスワードによる認証方式とは別に、いくらでも吐き捨て可能な認証ID公布方式を取りたいんだと。まぁ確かにそれならパスワードという、下手すりゃパンツの中身を見られるよりもダメージの大きい物を曝け出されるよりは、幾分ダメージが小さくなるのかもしれない。
ただしその為には、アプリケーションに付与される権限によってパスワードという秘密の園に到達出来ない仕組みが必要であり、かつ申請方式等といったとてもバカげた物を廃止する必要があり、全てオートメーションにかつMachine Readableに遂行出来る様にもすべきだと思う。
さらには既にあるアプリケーション、例えば私の「gtktweeter」についてのページがあり、そこからボタン一発(例えばforkボタン？)で入力情報がコピーされ新たな consumer key と consumer secret が付与されている...という位の自動化が成されない限りは、Twitterの目論見は失敗へと変わるだろう。

あと、cheebowさんからのコメント

cheebow

「連投しオフィシャルからbanさせるなんて事も可能です。」ってあるけど、この場合banされるのはこのクライアントを使った「ユーザ」だよね？　http://mattn.kaoriya.net/web/twitter/20100908165946.htm #Tw

http://twitter.com/cheebow/statuses/23966546230

上のTwitterの回答を見ると、どうやらbanされるのはアプリケーションの様です。実際どの様になるかは分かりませんが。

なお、gtktweeterについてはブラウザを起動してPINを入力させるという、極めてウンコな実装としてgithubにpushしておいた。ソースコードの CONSUMER_KEY と CONSUMER_SECRET を書き換えてコンパイルして使って下さい。えっメンドクサイ？だってTwitterがそうしろと言ったんだもん。

ところでTwitterさん、最後の質問「xAuth の許可を得るのにどれだけ時間が掛かるのか？」はどうなった？