2003年04月24日(木) [過去の今日]
#1 \noindent
LaTeXにこんなコマンドあったのね。てことは
\noindent 「こういうわけなのね」
みたいにすれば、小説とかのセリフ部はインデントされないわけか。s/^「/^\\noindent\ 「/ してからコンパイルすりゃいいのだな。しかしちと面倒だな。^「 にマッチするものはインデントしないというような自動処理はできんのかな。
(@038)
#2 ヤンサン
今週号を買ってみたら、小倉優子とかいうアイドル(?)のDVDが付いてた。280円の週刊誌にDVDが付く時代ですか。なんともまあ。
先日休刊したベーマガが、昔CD付けるようになった *1 時の事をなんとなく連想。価格が1000円くらいになってしまって、泣く泣く買うのをやめたのだよなあ。当時はV30マシンでCDドライブなんて持ってなかったので、見れないコンテンツに金を出すのはきつかったのだ。
それが価格据え置きでDVDを付ける週刊誌が出るようになるとはなあ。なんともかんとも、時代は変わるものだ。
って、待てよ。俺DVDドライブ持ってないぞ。当然DVDソフトも持ってない。てーことはなんですか。俺がはじめて所有したDVDソフトは小倉優子DVDですか。
………………………………………………………………………………うがあああああああああああああああ!
なんだ、この言い知れぬ不快感は……。
(@465)
#3 少額決裁システム
なんかウェブマネーなんぞ買ってみたりして思うのだが、やっぱり少額決裁システムは必要だなあと。やはりユーザーのアクションをもっと減らした形でないと、お金は動かないよなあ。
ということでなんとなく妄想してみる。
- まずISPが課金サーバを立てる。
- ショッピングサイトはユーザーエージェントから送られて来た課金サーバのアドレスにセッションを張る。
- 同時にユーザーエージェントは課金サーバにセッションを張る。
- ショッピングサイトは課金サーバに課金情報を送る。課金情報はアクセス元IPアドレス、価格、商品番号を含む。
- 課金サーバはショッピングサイトから送られて来た課金情報から、現在セッションの張られてるIPアドレスとマッチするか確認し、マッチすれば価格と商品番号をユーザーエージェントに送って確認を取る。
- 確認が取れたら、ユーザーエージェントのアクセス元IPアドレスをその時点で使用しているユーザーに対して課金する。
- 課金サーバは課金完了をショッピングサイトとユーザーエージェントに知らせる。
- 課金された料金はISPの月々の支払いと一緒にユーザーに請求される。
これならユーザーはYes/Noを答えるだけで済むのでとても楽だと思うのだが。
ISPじゃなくてもクレジットカード的な会社が課金サーバを立てればすむだろうか。
- まず課金会社が課金サーバを立てる。
- ショッピングサイトはユーザーエージェントから送られて来た課金サーバのアドレスにセッションを張る。
- 同時にユーザーエージェントは課金サーバにセッションを張る。
- 課金サーバはユーザーエージェントからのアクセスに対し、ショッピングサイトから送られて来た課金情報から価格と商品番号を、ランダムな文字列から生成したmd5sumとともに送って確認を取る。
- ユーザーエージェントはIDとパスワードをユーザーに対して「必ず」要求する。この時IDとパスワードをユーザーエージェントは保持してはならない。
- IDとパスワードが入力されたら、パスワードは課金サーバから送られて来たmd5sumとともに混ぜてmd5sumをとり、それIDとともに課金サーバへ送り返す。(APOPと同じ)
- サーバは送ったmd5sumとID、パスワードから同じ手順でmd5sumを取り、ユーザーエージェントから送られて来たものと一致するか確認する。
- 確認が取れなかった場合は再度ユーザーエージェントに要求を出すが、3回連続してマッチしなかった場合はアカウントを一時停止にする。(銀行のATMとかと同じ)
- 確認が取れたら、ユーザーに対して課金する。
- 課金サーバは課金完了をショッピングサイトとユーザーエージェントに知らせる。
- 課金された料金は課金会社それぞれのポリシーに従ってユーザーに請求される。
もっとセキュアにするならMD5よりも強い鍵を使えばいい。
なんにしても少額決裁システムの仕様はオープンでなくては普及しないだろうなあ。RFCかなんかで規定してくれないもんかね。
(@934)