この特集のトップページへ
＞
Chapter 8：プレゼンテーション層の構築
8.2.1 基本的なASPプログラム
●クッキー情報の送受信
説明はこのぐらいにして，クッキーを利用したサンプルをList 8-18とList 8-19に示す。
List 8-18は，ログイン画面を想定したものである。Fig.8-42のように，ログイン名（LOGINNAME）とパスワード（PASSWD）を入力するため，2つのテキストフィールドが装備されている。ここでユーザーがログイン名とパスワードを入力して［ログイン］ボタン（SUBMITボタン）を押すと，List 8-19のlogincookie.aspが実行される。
List 8-18とList 8-19のポイントは，クッキーを利用したユーザー名の保存にある。List 8-19の14〜20行目を参照してもらうとわかるように，この部分ではResponse.Cookiesコレクションを利用して，ログイン名をLOGINNAMEというクッキー情報に保存している。これにより，ユーザーによって入力されたログイン名がLOGINNAMEという名前のクッキーに保存される。
一方で，List 8-18の5行目では，“VALUE="<%=Request.Cookies("LOGINNAME")%>”と指定されている。これにより，LOGINNAMEという名前のクッキーに保存された値――すなわち，List 8-19で保存されたユーザー名である――が，ログイン名のテキストフィールドに表示される。つまり，ユーザーが一度ログインすると，次にList 8-18を参照したときには，以前に入力したログイン名が自動的にテキストフィールドに入力された状態になるのである。ただし，List 8-19では19行目にあるように有効期間を1日と設定している。そのため，1日経過すると，保存されたクッキー情報は破棄され，それ以降はログイン名がテキストフィールドに自動的に入力された状態にはならない。
実は，「クッキーが破棄される」という表現は正確ではない。クッキーを破棄するタイミングは，Webブラウザに依存する。有効期限が切れたクッキーは，もうサーバー側に送信されなくなるが，有効期限が切れたクッキーをいつクライアントの記憶領域から削除するのかは，Webブラウザ次第である。有効期限が切れたことを確認した段階ですぐに削除するWebブラウザもあれば，Webブラウザが起動したり終了したりするときにまとめて削除するWebブラウザもある。
List 8-18とList 8-19では，ログイン名のみを保存し，パスワードは保存していない。もちろん，同様の方法でパスワードを保存することも可能である。しかし，セキュリティを考慮すると，重要なパスワードをクッキーに保存すべきではない。クッキーは，クライアントの記録領域に暗号化されない状態で保存されるので，パスワード漏洩のおそれがあるからである。
ここで「暗号化されない」というのは，ネットワークにおける盗聴のおそれがあるということを述べているのではない。ネットワーク上での漏洩は，SSLを用いて通信網を暗号化することにより防ぐことができる。ここで述べているのは，ハードディスクに保存されたデータそのもののことである。クッキーはハードディスク上に暗号化されずに保存されるため，たとえ通信網が暗号化されていたとしても，クッキー情報が格納されたファイルを参照されてしまえば，通信網の暗号化はまったく無意味になる。
Fig.8-42 List 8-18，List 8-19の実行結果
○クッキー利用時の注意
いままで説明してきたように，クッキーを使うとWebブラウザ側にデータを保存することができるため，非常に便利である。しかし，クッキーを利用する場合には，いくつかの制限があるので，次の点に注意しなければならない。
すべてのWebブラウザがサポートするわけではない
クッキーは，すべてのWebブラウザがサポートするとは限らない。たとえば，携帯電話のi-Modeは，クッキーをサポートしていない。
また，ユーザーの設定によって，クッキーを使わないようにすることもできる。たとえば，Internet Explorer 5.5では，［インターネットオプション］の［セキュリティ］ページで，クッキーを無効にすることもできる（Fig.8-43）。
クッキーをサポートしない，もしくは無効になっているWebブラウザに対してResponse.CookiesコレクションやRequest.Cookiesコレクションを用いてもエラーにはならないが，そのクッキー設定は無視される。つまり，Response.Cookiesコレクションを用いてクッキーの値を取得しても，常にEMPTY値が返される。Fig.8-43 Internet Explorer 5.5におけるセキュリティの設定
クッキーは改竄されることがある
クッキーはクライアント側に保存されるわけだが，クッキー情報そのものには何らセキュリティが考慮されていない。したがって，クッキー情報が改竄されるおそれもある。たとえば，Windows 2000でInternet Explorer 5.5を利用している環境では，クッキー情報がC:\Documents and Settings\ユーザー名\Cookiesフォルダにテキストファイルとして保存される。ユーザーがこのフォルダ内に保存されたテキストファイルを書き換えれば，容易にクッキーを偽造することができる。クッキーは安全ではない
クッキーは，Set-CookieヘッダとCookieヘッダで構成された単なるテキストデータである。よって，ネットワーク上で盗聴されるおそれもあるし，クライアント側に保存された情報を閲覧されたり改竄されたりするおそれもある。
よって，漏洩してはならない情報をクッキーとして保存することは避けるべきである。大量のデータを保存できない
既述のとおり，クッキーではSet-Cookieヘッダによって送信されたデータをクライアントの記録領域に保存する。あまりに多数のデータを送信すると，クライアントの記録領域を越えることもあり得る。クッキーをサポートするWebブラウザは，（1）1つあたり4Kバイト以下，（2）1つのドメインあたり20個まで，（3）全部で300個のクッキー，をサポートするが，それ以上のクッキーをサポートするかどうかはWebブラウザに依存する。それを上回ったときには，Webブラウザによってはクッキー情報が無視されることがありうる。よって，クッキーを使って大量のデータを保存しようと思ってはならない。
なお，ASPではクッキーよりももう少し使いやすい，セッションという機構が用意されている。ユーザーが接続中の情報を一時的に保存したい場合には，必ずしもクッキーを利用しなくてもよい。セッションについては，「8.2.2 アプリケーションとセッション」で説明する。
 |
20/43 |  |
