このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
WWW 認証は HTTP によって規格化されており、
その機能を Web サーバ側に任せることで、
Web サーバの負担を最小限にすることができる。
しかし、WWW 認証にはいくつか問題点がある。
・認証ユーザの登録作業が Web サーバに依存している。
・認証手法への対応が Web ブラウザに依存している。
・認証情報が全てのリクエストに追加されてしまう。
・直接的な認証解除（ログアウト）手段がない。
・匿名アクセスを併用した「選択式」にできない。
昨日は Apache の例を示したが、
他の Web サーバでは方法が異なるため、
ユーザの管理も Web サイトで行う場合、
汎用的な CGI を書くのが難しくなる。
大規模な Web サイトで、
ユーザを別の認証サーバで管理している場合、
WWW 認証は利用できない場合も考えられる。
また、利用者が多数の Web サイトを開いていた場合、
一度全てのウィンドウを閉じる必要がある。
Web メールやグループウェアなどを併用している環境では、
これは利用者に負担を強いることになる。
HTTP で規格化されているのは良いことなのだが、
規模が大きいビジネスサイトを構築するためには、
セキュリティ面でも機能面でも、物足りない点が多いのだ。
そのため、現実的にビジネスサイトにおいては、
WWW 認証はほとんど使われておらず、
CGI やその他の後継技術を使った実装が多い。
CGI 等によって認証を行う場合は、
通常のフォームとして認証用のページを作り、
フォームの内容を、プログラムで検証することができる。
また、CGI 側でユーザの検証が完了した後は、
ユーザ名やパスワードの代わりとして、
CGI が任意に生成した適当な ID を使い、
より安全に通信を継続することができる。
この場合、静的コンテンツへのアクセスにも、
CGI を介在させる必要はあるが、
最近では Web サーバの性能も向上しているため、
それほど大きな負担ではなくなってきている。
また、CGI の起動負担を減らす仕組みや、
ASP や JSP など、Web サーバによる
より高度なプログラムサポート機構も存在するので、
WWW 認証のメリットは少なくなってきているのだ。