ただのにっき

■ いまごろGoogle Mapsを使ってみるの巻

登場当初から、おれのためにあるようなサービスだと思ってはいたのだ。何って、Google Maps API。なにしろウチには数百もの地理に結びついたコンテンツがあるのだから、これをGoogle Maps上にマップしないでどうしろというのか。

というわけで、最近は地図のアップデートはすっかりあきらめて、Mapionへのリンクだけ生成してお茶を濁していたこま犬ライブラリのデータを、Google Maps上に載せてみる。いまごろGoogle Mapsかよ、と言われそうだが、いいのだ。おれ、アルファギークじゃないもん。

こま犬ライブラリはtDiary BlogKitで作られているので、できればGoogle Mapsもプラグインとして実装したい。で、あれこれやってみたのだが、どうしても表示されない。そこで、試しに静的HTMLに保存して、文字コードをUTF-8にしてみたらあっさり出てきた。なんてこった。UTF-8前提という噂は聞いていたが、ここまで頑固だとは。これじゃぁ、tDiary上で動かすのはムリだねぇ。

というわけで、本体は静的HTMLにして、Javascript部分を別ファイルにして、各こま犬のページに埋め込んだmap_linkプラグインからデータだけ自動抽出するという方向に転換。そうしてできたのがコレである。うーん、こりゃラクチンだ。手動でクリッカブルマップを作るなんて、アホらしいね。

ともあれ、全国地図はこれでいいとして、都道府県別はtDiary上に作りたいな。これがUTF-8化のモチベーションになるか?

■ 涼亭茶話会

ただの飲み会になってる風味。あと、鯉の餌付け会。

■ OpenID認証の仕組み(2)

otsuneさんの提案に従い、ちょっとだけ図を更新。スクリーンショットは面倒なのでパス(^^;

実際にサービス提供者と認証サーバの間で行われるやり取りについてはぴろさんのツッコミを参照。いちおうOpenID仕様書(日本語訳)は流し読みしたんだけど、実はよくわかんなかったんだよね……。こういう、「てきとーなことを書いておいてあとはツッコミで訂正されるのを待つ」手法には何か名前をつけてもいいのではないか。NDOメソッド派生で。

図を描いて改めて認識したのは、あんまり強固な認証手段じゃないということ。図の[2][3]にMan-in-the-Middle攻撃をされたらひとたまりもないので、大事な情報には使わないほうがよろしい。一方、IDはそのままで認証サーバを簡単に変えられるのはメリットかも。うちも今、どうもTypeKeyの認証サーバがうまく動いてくれないので、夕べからVidentity.orgのサーバを使うようにしてある。プラグインでさくっと切り替えるだけ。

■ 意外な方面から執筆依頼が

ゆうべ、思いもよらぬ執筆依頼が飛び込んできて、ちょっとウケた。日記は書いておくもんだねぇ。

バイクのローンの足しになるならなんでもしますよ!……というわけでもないが、快諾。詳細後日。

■ 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が正しいものかどうかを確認できたので、ログインを許可する

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