_ mixiに招待してもらった (13:34)

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

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

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

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

_ リファラエディタプラグイン (14:44)

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

たぶん、refedit_loadの頭にでも、

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

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

_ とおんねーなー (15:34)

ひとまず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で書こうかなー。

_ TypeKeyクライアントサンプルCGI (21:04)

上記リンク先にアクセスして、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サーバー上で認証済み（セッション）なんで、ログイン画面なしで自動的にリダイレクトがかかる。で、どうやら認証状態で自動リダイレクトがかかる場合には、無条件でメールアドレスを通知するらしい。

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