ただのにっき

■ Streamripperその後

先月仕掛けたStreamripperだが、ほったらかしにしておいたらこんなことに:

% du -h ~/var/mp3
8.7G    /home/sho/var/mp3

% df
Filesystem 1K-ブロック     使用  使用可 使用% マウント位置
/dev/hda1     38811816 31140276 7671540   81% /

ぎゃ、もう10GB目前じゃん。RadioioJazzは64kbpsなので、128kbps換算にすると17GB相当である。ぜんぶ聴くのに何日かかるやら。つーかディスクの使用量が80%を超えてしまったので、しばらく休もう。

■ OpenID認証の仕組み(想像)

今日のパワポ仕事に飽きたので、余勢で1枚。

なんとなく盛り上がっていることを察してVidentiry.org上にページを確保したのはいいが、何が面白いのかさっぱりわからない人は、OpenIDの仕組みがわかってないのかも知れない。

1. ユーザはVidentity.orgのlogin画面で、IDの代わりに自サイトのURLを入れる。このときパスワードは入力しない(図の[1])
2. IDの代わりにURLを受け取ったVidentityのサーバは、それをOpenIDと見なして、指定されたURLからHTMLを取得する(図の[2]〜[3])
3. 取得したHTMLの中に<link rel="openid.server"...>なる要素を見つけたVidentityのサーバは、実際の認証がそのサーバで行われることを知る(うちの場合TypeKeyのサーバ)
4. さらに<link rel="openid.delegate"...>なる要素もある場合は、入力されたURLではなく、そこに指定されたURLが認証サーバ上における本当のIDだということになる
5. Videntityのサーバは、TypeKeyのサーバ(openid.serverの値)に対して、本当のID(openid.delegate)を伝え、「コイツを認証してくれ」と依頼する(図の[4])。実際にはけっこうややこしいやり取りがあるが省略
6. OpenIDを受け取ったTypeKeyサーバは、ユーザにTypeKeyのパスワード入力を促すページを返し(図の[5])、認証をする(図の[6])。ここもページ遷移にいろいろと工夫があるが詳細省略。重要なのは、ユーザはVidentity.orgではなくTypeKeyにパスワードを渡しているという点
7. TypeKeyサーバはVidentityに認証の結果を返す(図の[7])
8. Videntityは、(ユーザのパスワードを知ることなく)そのOpenIDが正しいものかどうかを確認できたので、ログインを許可する

ちなみに仕様書とかぜんぜん読まずに書いているので(ぉぃ)、ウソかもしんない。で、これがわかっても、現時点で面白いのはたぶん技術者だけ(笑)。