mixiに招待してもらったんでちょっとだけ触ってみたけど、なんかあんまり好きじゃない感じだなー。システムは結構良さそうだけど、現状の利用のされ方が俺の好みじゃない。

なれ合うならもっと狭く深くなれ合った方がいい。雰囲気しか見てないけど、あの程度の浅いコミュニケーションだったら、わざわざクローズドな場所でやるほどのものでもないと思う。まあmixiを使った深いコミュニケーションは、他人（非友達）には見えないところに隠れてるんだろうけどさ。

個人的な感触（願望）としては、SNSはもっとクローズドな用途でのみ使われるようになって欲しいな。で、ちょっとだけアクセス制御を使いたいけど基本的にオープンでかまわないようなコミュニティは、今までのWikiとか日記とかblogとか掲示板とかに、TypeKeyみたいな外付けシングルサインオンの仕組みを組み合わせて実現する方がいい。

たぶんmixiのアカウントは、単にmixi内のオープンな場所にアクセスする権利としてしか使わない気がする。とかいいつつ、どっぷりmixiにはまって一ヶ月後にはSNSサイコー！とか吠えていたら笑えるな。

とても便利なんだけど、バグらしきもの発見。その月の日記（というか%Y/%Y%m.tdrファイル）が存在しない状態で、プラグインを呼び出すとエラーが出る。具体的には、10月1日の日記をまだ書かない状態で、9月30日についたREFERER SPAMを削除しようとしたら、編集フォームを表示する前にエラーが出た。

たぶん、refedit_loadの頭にでも、

if File.exist?(path) == false then return {} end

とかつけておけばいいのかな？　もう今月の日記を書いちゃったんで、試すのは来月回し。

ひとまずTypeKeyの動作確認だけやっておこうかと、Authen::TypeKeyを使ってみたはいいけど、リダイレクトして戻ってきたパラメータを、

$q = CGI->new;
$tk = Authen::TypeKey->new;
$res = $tk->verify($q);

とかすると、

TypeKey signature verification failed

とか言われちゃうんですけど。なんか追加設定しないと使えないんだっけ？

ああそうか

verifyを呼ぶ前に、

$tk->token([TypeKeyトークン文字列]);

を入れないとだめなのね。これもちゃんとドキュメントに載っけておいてくれよ。

これで一応PerlでTypeKeyを使う準備はできたけど、PHPでDSAの署名をverifyするにはどう書けばいいんだろう。PEARにCrypt::DSAがあるかと思って見てみたら、まだなかった。TypeKeyのverifyだけPerlを使って、それ以外はPHPで書こうかなー。

上記リンク先にアクセスして、loginをクリックすると、TypeKeyの認証ページに飛ぶ。そこでログインするとリダイレクトして戻ってきて、名前、ニックネーム、メールアドレス（通知する場合）が表示される。

#!/usr/bin/perl
use CGI;
use Authen::TypeKey;
print "Content-type: text/html\n\n";
print "<h1>TypeKey test</h1>";
my $q = CGI->new;
my $tk = Authen::TypeKey->new;
$tk->key_cache([公開鍵用キャッシュファイルのパス]);
$tk->token([TypeKeyトークン文字列]);
my $res = $tk->verify($q);
if (!$res) {
print "LOGIN FAILURE: ".$tk->errstr;
} else {
my $name = $q->param('name');
my $nick = $q->param('nick');
my $email = $q->param('email');
print 'Your Name: '.$name."<br>";
print 'Your Nickname: '.$nick."<br>";
print 'Your Email Address: '.$email.'<br>';
#以降、$nameと$emailを使って、ローカルの認証を行う
}

ちなみに上記段階は、あくまでもTypeKeyの認証が行われただけの話で、実際に各Webアプリケーション上でそのユーザーにどのような権限を与えるかは、$name（と$email）を使って別途処理する（というか権限データベースを作る）必要がある。あと認証状態の継続（セッション管理）も、自前でやらないといけない。まさかアクションごとにいちいちTypeKeyサーバーにとばすわけにもいかないしね。

これを使ったアクセス制御のパターンとしては、

1. 未認証
2. TypeKey認証済み
3. TypeKey認証済み＋メール通知有り
4. TypeKey認証済み＋ローカルユーザー権限あり

というユーザー権限に対して、それぞれ読み書き権限を振り分けていく感じになるんでしょう。実際には4の段階で、さらに細かい権限設定ができるけど、それはまあ適当に。

そういえば、やっぱり前に書いた微妙な動作はサーバーサイドの挙動に問題があるんだね。

「メールアドレスを通知しない」を選ぶと、最初の1回は確かに仕様通り、メールアドレスとしてSHA1ハッシュを返すんだけど、ブラウザの戻るボタンでTypeKeyの認証ページに戻ると、すでにTypeKeyサーバー上で認証済み（セッション）なんで、ログイン画面なしで自動的にリダイレクトがかかる。で、どうやら認証状態で自動リダイレクトがかかる場合には、無条件でメールアドレスを通知するらしい。

ちゃんと動作させるためには、ユーザー設定で「常時メールアドレスを通知する/しない」とかをつけつつ、後は各サーバーごとにこのセッション中に「する/しない」のどちらを選んだのか覚えておいて、リダイレクト時にはその組み合わせを見ながら、適切に処理する（メールアドレス通知リダイレクト、非通知リダイレクト、メールアドレスを通知するかのみを確認するフォーム表示）感じかなー。

この本を持っている人にちょっと質問。この本って、カラー折りは先頭じゃなくて、途中に挟まるのが正解だよね？　なんか出だしにカラー折りでホームランシーンがあって、それとは全然つながらずに話が進んでいくんで、演出にしてもなんか変だなーと思ったら、中盤辺りにどう見てもここにホームランシーンが挿入されるはずの場所を発見した。肝心のページ周辺にページ数が書かれていないんだけど、80ページ〜104ページを数えてみたら4ページ飛んでいたし。すげーわかりにくい乱丁だなー。出版社に送って交換してもらうのも面倒くさいけど、Amazonで買った本だから本屋に持っていって直接交換ってわけにもいかないんだよなー。

BCMathモジュールは必須かなー。自前で書こうかと思ったんだけど、BCMathオプション付きでPHPをコンパイルしていなかったんで、やる気をなくしてしまった。基本的に、DSAのverifyって大規模整数演算ができれば何とかなるんだよね。

話題になっていたんで買ってみたんだけど、なんかあまり面白くなかった。アニメーター業界裏話的には面白いんだけど、なんだかやけにオチが付かない話の連続で、まあ現実に起きる出来事はきれいにオチが付くものではないんだよ、というテーマでもあるんだったらいいけど、じゃなかったらもうちょっとそれなりにいちいちオチをつけて欲しいなー。

このシリーズはファンなんで、もはや何を読んでも面白いんだけど、今回はなんだかちょっとぎくしゃくしている部分が多かった気がする。今回の村の設定が、何となく人狼BBSと重なって……ってのは毒されすぎだな。村長と息子が共有者でした。

親指が分かれてるやつね。雨の日は水が入る。

万歩計らしい。イラストダセェ。