Apache::RequestからPOSTデータがとれない!?

うおーーーーー、Apache::RequestからPOSTデータがとれない！！なぜだーと小一時間悩んでいたら、こんなコード書いてました。

>

sub handler {
my $r = Apache::Request->new(shift)
my @keys = qw(foo bar baz);
for my $key ( @keys) {
my $val = $r->param($_);
warn "$val\n";
}
}

<

原因に気づいて愕然としました。。。

livedoor Reader いい！

先日ベータ版がリリースされたlivedoor Readerを使ってみました。

恐ろしく快適です。
記事をバックグラウンドで先読みしてくれていて、動作が軽快です。
さらに、キーボードショートカットが超便利。
s,a,j,k,spaceを使えば記事を次々読んでいけるし、気になる記事はpでピンをうっておいて、oで別ウィンドウで表示できる機能は恐ろしく便利です。
まら、oで別ウィンドウを開く際、ブラウザのポップアップブロックで別ウィンドウが開けないと、その旨をメッセージ欄で教えてくれたり、IMEがオンになっている状態でショートカットキーを使おうとすると、ショートカットを使うにはIMEをOFFにしてくださいと親切に教えてくれます。すごく細かいところまで作りこまれているなーと感動しました。

なんてことをやっていたら、午前中が終わってしまった。。

LWPのバージョンあげたらファイルアップロードが遅くなった

ここ最近AtomPPを使ったサービスを作っているんですが、そのためにXML::Atomをインストールしたら、LWPを使って１０MBくらいの大きいファイルをアップロードすると異常に時間がかかるようになってしまいました。
アップロード時のサーバの様子を見ているとメモリとCPUをやたらと消費しているようです。

LWPのドキュメントを読んでいるとHTTP::Request::Commonのドキュメントに$DYNAMIC_FILE_UPLOADをTRUEにセットすれば大きなファイルをメモリをあまり使わずにアップロードできるよと書いてあったので、これをTRUEにしたところ、劇的にアップロードの時間が短縮されました。

めでたしめでたし。

Sledge::Plugin::FormValidator::Simple-0.02

Sledge::Plugin::FormValidator::Simpleを0.02にバージョンアップしました。



Sledge::Plugin::FormValidator::Simple-0.02


0.01ではリダイレクト先やプロファイルをメソッドを定義することで変更できるようにしていましたが、あんまりかっこよくない気がしたので、メンバ変数として定義するようにしよう変更しました。

それと、valid_before_foo, valid_after_fooを定義することができるようにしました。
使い方はこんな感じです。

>

sub valid_before_foo {
my $self = shift;

# change profile by query param.
if ( $self->r->param('step') == 2 ) {
$self->validator->profile_name($self->profile_name . ".step2");
}else {
$self->validator->profile_name($self->profile_name . ".step1");
}

# change redirection when error is found.
$self->validator->redirect_url('/');
}

sub valid_after_foo {
my $self = shift;
my $results = $self->validator->results;
if ( found some error... ) {
$results->set_invalid('param3' => 'MY_ERROR');
}
}

<

JavaScriptでのバリデーションはまた後日対応したいです。

WSSE認証で使用するパスワードにハッシュ化した文字列を使うのはどうか？

ここ最近APIの認証について、考えてます。

AtomAPIの認証として事実上標準的に使われているWSSE認証ですが、APIを提供しているサービスにログインするためのパスワードとAPIの認証用パスワードを共通にした場合、APIを利用するクライアント側に生のパスワードを持たせる必要があるので、APIを利用したサービスでパスワードがもれた場合、そのパスワードを使って、提供側のサービスにもログインできてしまうということになりえてしまいます。

かといってサービスログイン用のパスワードと、API認証用のパスワードを別々に設定するようにすると、ユーザはパスワードを二つ覚えておく必要があるので、ちょっと、めんどくさーとか、わすれたーとなってしまいそうです。

そこで、パスワードは1つで済んで、APIを利用する側のアプリでパスワードがもれたりした場合も、本サービスではそのパスワードを使ってログインできないようにする方法として、APIで使用するパスワードは生のパスワードをハッシュ化したものを使うというのはどうだろうかと考えています。

こうしておけば、APIを利用するアプリ側も生パスワードを持たなくて済むので、なんとなく気持ちが楽になるのかなと。結局ハッシュ化した文字列がパスワードのかわりになるだけなので、これがもれるとAPIの認証はできてしまうんですが、APIで触れる範囲はログインしてできる範囲より小さいと考えられるので、被害は小さくなるのかなと思いました。