ClickOnce

いつものことだが、思いつきのメモなので、的外れかもしれない。
ClickOnceのアプリケーションでユーザの認証をすることを考える。認証用のデータは当然サーバにおくべきだろう。すると、クライアントから、サーバに認証の確認の要求をする必要がある。
webサービスを使うことにしよう。サーバにIISが必要になる。(まぁ、よしとしよう) webサービスの実装はASP.NETなので、認証機能が使える。継続的にサーバとやり取りするなら、セッション管理も利用できる。

さて、HTTPだとパケット見られたら、多分、ばれてしまうだろう。かといって、HTTPSにすると証明書が面倒だ。自前で、暗号化することにしよう。
パスワードを生(raw)にせず、クライアントでハッシュにしよう。単なるハッシュだと、ばれたら一緒だ。クライアント固有の情報とパスワードを合わせてハッシュを作ろう。クライアント固有の情報も偽装されないようにするのは、大変だ。サーバで作ってやろう。
結局、こうだ。

• サーバで、IDとパスワードを管理する。
• クライアントからサーバに、Webサービスでワンタイム情報を要求する。
• サーバでワンタイム情報(S)を作成し、(ID,S)をリストに追加し返す。
• クライアントで、パスワード(P1)とSから、ハッシュ値(H1)を作り、H1をパスワードとして認証要求する。
• 認証要求されたサーバは、IDからパスワードP2とリストからSを求め、ハッシュ値(H2)を作る。リストから、キーIDは削除する。
• H1とH2が同じならば、認証OKとする。

この方法のデメリットは、2回呼ぶ必要があることと、2回の間で割込まれたら、不正に認証されてしまうことだ。
（ワンタイム情報は、パスポートの申請でつかわれる確認はがきのようなものかな。）

株式会社に罪はない。法人が刑務所に入ることはできない。もしあるとすれば、誰が罪を負うのか。株式会社の所有者である株主か。株主の責任範囲は明確に決まっており、出資リスクだけだ。株式会社の販売した商品に欠陥がある場合、購入者は、売買契約に則ったことしか要求できない。（もちろん契約にないからといって突っぱねて社会的イメージを損なうことを推奨しているわけではない）社会的影響範囲が大きいと認められる場合、経営者は早急に手を打たなければならない。基本は、真摯に対応することである。

顧客からソフトの無償バグ対応の期間に対し、疑問を投げかけられた。ハードでも保証は無期限ではないが、一般にソフトの方が短い。 1年、半年などである。
ソフトは目に見えないため、不具合が分かりづらい。従って、保障期間後にバグが見つかることもままあるだろう。（別途保守契約を結ぶことにより、対応することも多い。）
無償保障期間を長くすると、その分、金額に跳ね返り、販売機会を逃しやすい。また、リスクのぶれも大きい。これらの原因の1つは、ソフトの複雑さである。ソフトの複雑さを扱う方法が必要だ。