Tutorial - CGI::Sessionのさらに広範囲に渡って記述されたマニュアル HTTPはステートレスなプロトコルですので、WEBサイトに対するそれぞれの webサイトに対するクリックはwebサーバーによって新しい訪問として扱われます。 サーバーは直前の訪問とは無関係です。したがって全てのそれ以前のリクエスト からの状態は失われます。このことによってショッピングカートや、 ログイン認証ルーチン、セキュリティー上の制限を設けるようなサービスなどは web上で不可能になります。よって人々はHTTPが我々を絶望的な状況に投げ入れる ことに対して何らかの対策を取らなければなりませんでした。 我々を救うべく、一定期間ユーザーのセッションを保つHTTPクッキーや クエリ文字列と言った技術が誕生しました。クッキー及びクエリ文字列だけでは RFC 2965, Sesctoin 5, "Implementation Limitations"に記述されている通り 我々を救うにはほど遠いものがあり、いくつか別のライブラリ/技術がさらなる 機能とさらなる信頼性、及び継続性を保つシステムを約束するために 開発されています。CGI::Sessionはそれらの中の一つです。 このライブラリを議論する前に、代わりの解決方法を見てみることにしましょう。 クッキーはwebサーバーに権利が与えられたユーザーのハードディスクに配置される テキスト情報の断片であり、ユーザーエージェント(例えばWeb Browser)に 特化した部分で互換性があると仮定します。クッキーが配置されると、ユーザー エージェントはサーバーアプリケーション(CGI)は同一のユーザーエージェン トによる過去のリクエストに関連した手段を持つことができます。したがって HTTPのステートレスと言う特性に打ち勝ったと言えるのです。 しかしながら、クッキーはHTTPのステートレスと言う特性に対する解決を約束す るものであるような気がするものの、ドメインやユーザーエージェント数毎のクッキー 数の制限やクッキーごとのサイズと言った制限が存在します。ユーザーエージェ ントは少なくとも一度に300個、ドメインごとに20個でかつクッキーごとに 4096バイトの格納を許容することが求められます。 それらの事項に対し、いくつかのプライバシーおよびセキュリティに関する 懸念が浮かびあがります。それらの懸念はRFC 2965における6-"PRIVACY"および 7-"Security Considerations"の各節にリストされているのを見付けることが できるでしょう。 クエリ文字列とはこのようなURLのクエスチョンマーク(?)に続く文字列です。 おそらくあなたは既にこの解法を使っていたのではないかと思われます。 クエリ文字列でも別の場所へのクリックによって状態を渡す助けになりますが、 あなたはどれだけ安全なものかと言うことを考えていますか？これらのURLが 大半のユーザーエージェントによって誰もがアクセスできるサーバーのアクセスログに 残るケースが頻繁であることを念頭に置くと、安全であるとは言い難いと言えます。 隠しフィールドはクエリ文字列の代わりに使用されるもう一つの選択肢であり、 隠しフィールドはPOSTメソッド及びGETメソッドの両方で用いられると言う 特性があります。GETメソッドで用いられる隠しフィールドは一度サブミットされると 本物のクエリ文字列に返信してしまうため、クエリ文字列を送信するのと比べて 何の進歩もありません。しかしながらPOSTリクエストは姉貴分であるGETのような 制限が無いのですが、それらを持つページをブラウザによってキャッシュさせる ことができ、(もちろん)ページのソースコードの範囲で有効になってしまいます。 多数のステート情報を記憶させておくとなる際にも扱いにくくなります。 (例えばショッピングカートや優れたサーチエンジンです。) クエリ文字列及び隠しフィールドはブラウザを閉じるか、さもなくばブラウザの "戻る"ボタンをクリックすることで簡単に失われてしまいます。 このテクニックは前述した技術にサーバーサイドでのストレージデバイスを プラスしたものを基に構築されており、状態のデータを特定のセッションとして 保存します。それぞれのセッションはサーバー内のデータによって連想された ユニークなidを所持しています。このidはユーザーエージェンと側でクッキーや、 クエリ文字列や隠しフィールド、又はその全てを同時に行う言ういずれかの形でも 連想されます。 進展した箇所: 私達はもはやクッキーの量やサイズと言ったユーザーエージェントの制限に 依存する必要が無くなったのです。 ユーザーのユーザー名やEメールアドレス、嗜好のようなきわどいデータ類は もうそれぞれのリクエストごとにネットワーク上を行き来する必要がなくなったの です。(クエリ文字列、クッキー及び隠しフィールドに対してのことを言っています)。 ネットワーク上を行き来するのはセッションのために生成されたユニークなidのみで (例えば"ID-1234"です)、例えどんな悪意をもつ者にとっても意味をなさないはずです。 ユーザーはセキュアでない平文型式のデータ(クッキーファイルのことです。)が コンピュータ内に保存されていることに神経を尖らせる必要が無くなるのです。 巨大で複雑でさえもある(メモリ内の)データ構造を透過的に扱うことが可能と なります。 これがCGI::Sessionに関する全てです - サーバーサイドセッション管理の実装。 今こそそのぬかるみから足を踏み出すチャンスなのです。 もしあなたがサーバーサイドセッション管理システムを扱ったことが無い場合、 それが凄まじく入り組んだ物のように思えるのかもしれません。好運なことに、 CGI::Sessionにおけるこの扱いにくい処理はエレガントな手法によって、 ライブラリを用いることで全ての複雑な箇所を透過的に扱うことを可能にするのです。 マニュアルのこの節ではセッション管理の背後にあるロジックと、CGI::Sessionの プログラミングスタイルについての両方の導入チュートリアルとして扱ってもらって 不遜はありません。 CGI::Session 3.xの文法は以前のリリースから変貌を遂げました。しかし我々はまだ 前バージョンと互換を取るために、継続して古い文法をサポートし続けています。 そのため、3.xインターフェースの初期のリリースに関して我々は'-api3'スイッチを 導入しました: これによってライブラリに新しい文法を使うことを伝えるのです。しかしライブラリの 最新リリースでは、それを自動的に探知するでしょう。つまり"-api3"スイッチをもはや 呼び出す必要が無くなるのです。あなたが古い2.xのapiをもう使わないというならば、 我々にそのことを尋ねるのはどうかお止め下さい。我々はあなたに何も教えない でしょう。 しかし本ライブラリを使い始める前に、どこにどうやってセッションデータを ディスクに保存するのかを決断する必要があるでしょう。言い替えればどのドライバ を使うのかを伝えなければなりません。あなたはデフォルトでディストリビュー ションに搭載されている"File", "DB_File"及び"MySQL"ドライバのいずれかを選択 することが可能です。このドキュメントでは要求するものがもっとも少ないため 理解しやすい"File"ドライバを用いた例を示します。実行するには次のように セッションオブジェクトを作成して下さい。 '/tmp'}); ]]> 一つ目の引数は呼び出されるデータソース(略してDSN)の名前です。undefであれば、 ライブラリはデフォルトのドライバ、「File」を使用するでしょう。よって、 下記の例のようにドライバに関しては明示的に示す代わりにこのように表現する ことも可能です: '/tmp'}); ]]> これにより、デフォルトの設定になることが保証されます。 ２つ目の引数は初期化用のセッションidです。もしundefであれば、CGI::Sessionに 新しいセッションを強制的に作らせます。session idを渡す代わりに、CGI.pm オブジェクトを渡すか、さもなくばcookie()あるいはparam()メソッドのいずれかを 実装したオブジェクトを渡すことも可能です。このケースでは、ライブラリは CGISESSIDクッキーあるいはCGISESSIDCGIパラメータ(クエリ文字列)の いずれかよりセッションidを取得しようと試みるでしょう。 ３番目の引数はハッシュのリファレンスと言う形であるべきです。これは特定の CGI::Sessionドライバにのみ適用されます。使用可能な全属性の一覧を見たい場合は それぞれのCGI::Sessionドライバを参照願います。 File - 平文でセッションデータを格納するためのデフォルトの ドライバです。フルネーム: CGI::Session::File DB_File - BerkelyDBにセッションデータを格納します。 必要物: DB_File。フルネーム: CGI::Session::DB_File MySQL - MySQLテーブルにセッションを格納します。 必要物DBI及びDBD::mysql。フルネーム: CGI::Session::MySQL Note: あなたは本ライブラリのためにドライバを自身で書くことも可能です。 このマニュアルの詳細の各節を隅々まで御覧下さい。 ユーザーに対する新しいセッションと言う焼き印を生成するためには、コンストラクタ - new()に未定義の値を２つ目の引数に渡すだけで構いません。 "/tmp"}); ]]> ディレクトリはセッション分散したファイルの形で格納されるであろうファイル及び そのロックの場所を示します。セッションオブジェクトを生成する際には 私が上記に示したことをするために、次の手順が踏まれるでしょう: 1 あなたのためにセッションIDは生成され 2 あなたが指定したディレクトリ中からidによって格納されたファイルが連想されます。 これからは、あなたが新しく生成されたセッションidにアクセスしたい場合は ただこうすれば良いのです。 id(); ]]> クッキーとして送信される、あるいはクエリ文字列やフォーム内の隠しフィールドと してそのまま用いられることが可能なa983c8302e7a678a2e53c65e8bd3316と言った 文字列を返します。 cookie(CGISESSID => $session->id); print $cgi->header( -cookie=>$cookie ); ]]> もし上記の方法が無理であれば、CGIの詳細を御覧下さい。 ユーザーが他のリンクやちょっと間を置いてサイトを再訪問した際、我々は再び 新しいセッションを作成しなくてはならないのでしょうか？もちろん違います。 これではセッションの維持と言う目的を打ち負かしてしまうことになるのですから。 我々がクッキーとして既にidを送信していたら、我々が皆必要とするものは セッションオブジェクトが生成されている間２つ目の引数としてそのidを渡すこと のみです。 cookie("CGISESSID") || undef; $session = new CGI::Session(undef, $sid, {Directory=>'/tmp'}); ]]> 下記の文法ではまずはじめに既存のセッションデータを初期化しようとし、もし 新しいセッションファイルを生成する場合(セッションが存在しない場合)でも、 我々が意図した結果となります。しかし、もしユーザーがクッキーをサポート していない場合はどうなるのでしょうか？その場合我々はクエリ文字列として全ての urlに追加する必要があります。クッキーを追加する方法を御覧下さい: cookie('CGISESSID') || $cgi->param('CGISESSID') || undef; $session = new CGI::Session(undef, $sid, {Directory=>'/tmp'}); ]]> あなたがCGIオブジェクトの扱いに長けていると仮定して、上記の２行を１行に 納めることが可能です: "/tmp"}); ]]> もし２つ目の引数として文字列の代わりにオブジェクトを渡すと、CGI::Sessionは クッキーあるいはクエリ文字列からセッションidを取得しようと試み、適宣に セッションを初期化します。クッキー及びクエリ文字列のパラメータはデフォルトで CGISESSIDであると仮定します。この設定を変更するためには、CGI::Session あるいはそのオブジェクトのうちいずれかのname()クラスメソッドを呼び出す 必要があるでしょう: name("MY_SID"); # 又は ]]> name("MY_SID"); ]]> '/tmp'}); ]]> param()メソッドを用いてオブジェクト内に値を一つ格納するためには: param("my_name", $name); ]]> あなたは配列や、ハッシュやオブジェクトなどのような複雑なデータを格納するために param()メソッドを用いることが可能です。配列及びハッシュを格納する際は、 リファレンスとして渡さなければなりません: param("fruits", \@my_array); ]]> 同様にオブジェクトも格納することが可能です: param("cgi", $cgi); # CGI.pmオブジェクトを格納します ]]> あなたが望むセッションオブジェクト内にCGIのパラメータを全て格納する方法も 存在します。あなたはセッションオブジェクトに各フォームの要素からの あなたは後で多数のクエリパラメータを格納しなければならないためににこの形式を 望むことだと思われます。以下の文法を御覧下さい: save_param($cgi, ["keyword", "category", "author", "orderby"]); ]]> save_param()は上記の全CGIパラメータをセッションオブジェクトに格納させる でしょう。これは以下と同様のことを言っています。 param("keyword", $cgi->param("keyword")); $session->param("category", $cgi->param("category")); # など全てのフォーム要素に対して ]]> 全CGIパラメータを保存したい場合ですが、save_param()の２つ目の引数を省略 するだけです: save_param($cgi); ]]> 上記の文法は全ての使用可能/アクセス可能なCGIパラメータを保存します。 もしあなたがデータにアクセスできないならば、保存されたデータに接点がないの です。あなたは一度データを保存するのに用いた同じparam()で保存されたデータに アクセスすることが可能です。 param("my_name"); ]]> 上記のparam()の形式では"my_name"として過去に保存されたセッションのパラメータを 取得します。過去に保存された@my_arrayを取り出すには: param("fruits"); ]]> 配列へのリファレンスが戻って来るでしょう。そして、@{$my_array}として参照する 事が可能です。 あなたはユーザーの好みや以前のアクションに応じた入力済、あるいは選択済の ラジオボタンやチェックボックス、ドロップダウンメニューなどのフォームを とても頻繁に作らなくてはならないだろうことにお気づきであると思われます。 textやtextareasならそれほど大したことではありません: 単に一つのパラメータを セッションから取得し、textフィールドにハードコーディングすれば良いのですから。」しかしラジオボタンやチェックボタン、スクロールするリストのグループを 扱うとき、あなたはどうするでしょう？この目的のため、CGI::Sessionはload_param() メソッドを提供しており、CGIオブジェクトに与えられたセッションパラメータを 読み出します (save_param()メソッドあるいはその他の選択肢で過去に保存されている と仮定して): load_param($cgi, ["fruits"]); ]]> さて、CGI.pmを使って選択済のチェックボックスを生成するには: checkbox_group(fruits=>['apple', 'banana', 'appricot']); ]]> もしあなたがHTML::Templateを用いることでスキンからコードを分離させる場合、 HTML::Templateを用いてCGI::Sessionオブジェクトをassociateすることによって 同様のことが可能になります。我々はこのトリックが大好きです。 "some.tmpl", associate=>$session); print $template->output(); ]]> HTML::Templateでassociateする間、セッションオブジェクトに"first_name"及び "email"パラメータが格納されていると仮定すると、"some.tmpl"ファイルを用いて それらの値にアクセスできます: "> ! ]]> HTML::Templateによるさらなるトリックを知りたい場合はライブラリマニュアル (HTML::Template及びCGI Session CookBook。 通常あなたは明示的にセッションを閉じる必要はありません。プログラムが終了する か、あるいはセッションオブジェクトがスコープからはずれた際、セッションが閉じ られます。しかしながら時にはCGI::Sessionの<close()>メソッドあるいはオブジェ クトを未定義にすることによってセッションを明示的に閉じたい場合があるかもしれ ません。セッションを閉じるとは一体全体何なのでしょう？ - あなたは尋ねるでしょ う。セッションがアクティブな間、ディスク内のセッションオブジェクトの更新が すぐに行われるわけではありません。flush()メソッドでバッファをフラッシュさ せると言う選択肢をとるかあるいはプログラムを終了させるかあるいはclose()メソッ ドを明示的に呼び出してセッションを破棄するまではメモリ内に保存されます。 状況によってはセッションを閉じたいもののプロセスをしばらくの間終了させたくない 場合もあるかと思われます。おそらくそのようなケースはGUI及びデーモンアプリケー ションによるものであると思われます。この場合close()こそがあなたが求めていたもの なのです。Note: 我々はclose()よりもシンプルな開放用のメソッドを好みます。 (close()は機能面で劣ります。) もしあなたがセッションをオブジェクトを何らかの理由でバッファ内のデータと ディスク内のデータを同期させたいならば、flush()こそあなたの求めるものです。 Note: close()も同様にflush()を呼び出します。したがってclose()を呼び出す前に flush()を呼び出す必要は全く無いのです。 セッションデータを保存し、セッションデータにアクセスすると、ある時点で 全てでなくとも、特定のセッションデータをクリアしたくなるでしょう。この目的の ためにCGI::Sessionはセッションパラメータをオブジェクトから消すべきパラメータ 名を指示した配列のリファレンスの表現で引数を一つ取るclear()メソッド をオプショナルで提供しています。 clear(["~logged-in", "email"]); ]]> 上記の行ではセッションパラメータ"~logged-in"及び"email"をセッションから消去し ます。そして次にこうすると: param("email"); ]]> iundefが戻ります。もしclear()の引数を省略した場合、あなたが今までにセッショ ンオブジェクトに格納したセッションパラメータが削除されてしまうのでお気を付け 下さい。セッションそのものを消してしまうのではないことを念頭に置いて下さい。 セッションはまだ開いていてアクセス可能です。中に格納されたパラメータが消去 されただけなのです。 もし始まりが存在し、終わりが存在するならば。もしセッションが作らるなら ば、それはディスクから削除することが可能である方が良いに決まっています。 delete(); ]]> 上記のようにdelete()を呼び出すことによってディスクからセッションを削除 した方が好ましいと言えます。clear()と混同しないように、これは特定のセッシ ョンパラメータをクリアしますが、セッションは開いたままです。 CGI::Sessionはセッションデータの期限切れを実現するための限られた機能を提供 します。セッションの期限切れはdelete()経由で消去することと同等ですが、削除は 自動的に行われます。セッションを期限切れにするためには、ライブラリに最終アク セス時からどれだけ長く有効であるかを教える必要があります。時間が来れば、 CGI::Sessionはセッションを取得することを拒否します。そのことによりセッション は削除され、真新しいセッションが返って来ます。セッションに対する期限切れを 示す時計を割り当てるためにはexpire()メソッドを用います。 expire(3600); # 3600秒後に期限切れになります $session->expire('+1h'); # 1時間後に期限切れになります $session->expire('+15m'); # 15分後に期限切れになります $session->expire('+1M'); # 1ヵ月後に期限切れになります ]]> しかし時には、セッション全体に対する有効期限の代わりに完全に特定パラメータ のみに限定した有効期限を設定することもできます。作者はログイン成功後に "_logged_in"フラグを真に設定し、30分間と言ったある有効期限をフラグに割り当てる ようなログイン/認証可能なサイトでこのことは大抵行われています。これは30分間 アイドルした後、CGI::Sessionが"_logged_in"フラグをclear()し、もう一度ユーザー はログインしなおさなくてはならないことを示しています。私は単にexpiring()を セッションそのものによって成し遂げられ得るのと同じであることを認めますが、 これらの方法ではその他のセッションパラメータが失われるでしょう。ショッピング カートなどのセッションではこちらの方が好ましいと言えます。 この形式では個人のプロフィール情報に対するログインに成功してから10時間まで 放っておいてもアクセスし続けることが可能ですが、10分間放っておくとクレジット カードへのアクセスの期限が切れると言った、階層化されたセキュリティ認証をシミ ュレートするのに用いることも可能です。 expire(_profile_access, '+10h'); $session->expire(_cc_access, '+10m'); ]]> 上記の文法によって5時間放置したとしても、まだ個人情報にはアクセス できます。しかし、クレジットカード情報にアクセス、あるいは更新しようとしても、 おそらく「もう一度ログインして下さい」とスクリーンに表示されることでしょう。 このことによりCGI::Sessionのプログラミングスタイルの議論に対する ひとまずの結論を下します(少なくとも新しくライブラリをリリースするには 至りました)。 マニュアルの最後にはドライバを実装する、あるいはライブラリの構造について理解 したい方々のために"セキュリティ"問題及び"ドライバの特性"をカバーしてい ます。 「どうやったらCGI::Sessionをセキュアに使えるの？」、「もしセッションユーザーの セッションidを取られてしまったら他の人が別のブラウザを使ってセッションを 乗っ取ることができてしまうの？」、「セッションidは推測可能なの？」と言った 私自身何度も何度も答えていることに気づいた質問群です。 ライブラリのセキュリティは実装に依存する局面が多いと言えます。このライブラリを 利用した後は、あなたはもうセッションidに関するユーザーのクッキーに対する情報を 送らなくても良いのです。しかし、あなたはまだサーバー側にデータを保存しなくては なりません。よってもう一つの疑問が挙がって来ます。それは悪意のある人が サーバー内のセッションデータにアクセスできやしないか、さらに想定外のデータが 含まれるセッションデータを作れやしないか、そしてさらにセッションを作った人に 対する情報が不正流用されやしないかと言うことです。いいですか、その答えはそれ を実装するあなたによるのです。 最初のルールの概要ですが、セッションの中にはパスワードやその他きわどいデータを 保存しないことです。もしあなたが自分でこれが重要であると認識したらば、きっと 悪の目玉はサーバー内のセッションファイルにアクセスすることもないでしょう。もし あなたがMySQLのようなRDBMSドライバを使っているのであれば、データベースは ユーザー名/パスワードのペアで保護されているでしょう。しかしもしそれが平文の 形でファイルシステムに保存されているとしても、きっとあなたを除く誰しもがそれ らのファイルへアクセスできないでしょう。 デフォルトのドライバの設定ではディスク内に保存することを可能にするために データをシリアライズするData::Dumperクラスを使用させることになります。 Data::Dumperの出力結果は人間が可読であるデータ構造なのですが、 このデータをオープンすればあなたが解読することができるのです。 もしStorableか又はFreezeThawのいずれかをシリアライザとして用いるために、 セッションオブジェクトを設定した場合は悪意のある者に対抗してセッション データとは無関係で意味なさないような複雑なデータを生成するでしょう。 しかしこのことをセキュリティのための警戒として用いてはなりません。 悪の指はセッションファイルを復号するStorableあるいはFreezeThawを用いた 高速なセッションデータ復元プログラムをたやすく書いてしまうのです。 セッションファイルの中身の更新に関して気を病むのも良くないことです。も ちろん、CGI::Sessionを用いる限りそのようなことは起こりませんが、 心配したところで別段害があるわけでもありません。 貴重なデータを伴うセッションを長期間保持してはなりません。このことにより、 悪意のある者が時間内に誰かの有効なセッションidを盗む可能性が増大します (なんらかの方法で知って)。 常に"-ip-match"スイッチを使いなさい！！！ 詳細は"-ip-match"にあるので読みましょう。 セッションidが簡単に推測されることはありません(Incr Idジェネレータを用いない 限りは)!CGI::Sessionにおけるデフォルトの設定ではDigest::MD5はプロセスid、 エポックからの秒数およびランダムな数字を用いて32文字長のダイジェストを 生成します。しかしながらこの文字列は他人が推測することは不可能で、もし 何らかの方法で見付けることができたとしても、他人の識別子を使うことなど できるのでしょうか？ あなたはただ誰かにemailかインスタントメッセージ経由でオンラインアカウントの プロファイルへのリンクを提供するところで現在ログインしていると言う シナリオを考えてみましょう。あなたがその人に提供するURLはクエリ文字列の一部 としてセッションidを含んでいます。もしそのサイトがセッションを初期化して、 ただクエリ文字列のパラメータを用い、今サイトに現れた人があなたであることを 示すリンクをクリックすると、ただちにあなたの機密データの全てにアクセス したかもしれません。なんと恐ろしく無知な実装なのでしょう。セッションidを 伴ったURLを貼り付けることが、事故が起こるのを待つようなものであることを 知らないなんと哀れなお子様なのでしょう。 もしあなたが単にクッキーをセッションidの転送役として用いた場合でさえも、 同じクッキーファイルの中に同じセッションidを伴うクッキーを植え込み、webブラウザ に適切なセッションidをサーバーに送信するよう細工することは難しいことでは ないのです。よって、もし私達にセッションデータを取得するよう依頼している人が 実際にセッションデータを最初に初期化した人であるかどうか、セキュリティ用の キーをチェックすべきです。CGI::Sessionではライブラリを「使って」いる間、 "-ip_match"スイッチを使用加納にすることによってこのようなケースにあなたが注意を 注ぐことを手助けします。 代わりの手段として、$CGI::Session::IP_MATCHに1と言った真を示す値を設定 する方法があります。このことを行うことによって、セッションのデータ格 納に備えた初期化の前に、セッション中に格納されたipアドレスとユーザーが 該当セッションに対して尋ねた際のipアドレスとが一致するか否かを検証し ます。ライブラリがセッションを返すようなケースでは、一致しなかった場合 適切なエラーメッセージとともにdieします。 この節は本ライブラリに対する独自の格納メカニズムを実装したいドライバの作者の ためのものです。同様にがらくたのサブクラス化を楽しむ人々はこの節が便利なもの であると気づくべきです。をここで我々はCGI::Sessionおよびそのドライバの構造を議論します。 ライブラリはメソッド節にリストされた基本メソッドを提供しています。 CGI::Sessionが自ら進んで提供しないメソッドはセッションデータを書き出す処理、 ディスクからセッションデータを取得する処理、そしてデータを消去する処理を 必要とするメソッドのみです。これらはドライバに特化したメソッドであるため、 それらが所属するべきところにあるのです。 言い替えるならば、ドライバはCGI::Sessionを基底クラスとして用いたもう一つの Perlライブラリであり、ディスクアクセスの処理を行ういくつかの付加的なメソッド を提供します。 ドライバの使用の話に入る前に、データがどうやって格納されるかについてお話しして おきましょう。flush()が呼び出されるか、さもなくばプログラムが終了した際に、 CGI::Sessionはディスクのどこに格納するのかを尋ね、そしてハッシュのリファレンス の形でデータが渡されます。それからデータをディスクに格納するデータをシリアラ イズ化するのはドライバの責任です。 あなたはドライバに独自のシリアライズ化の実装を組み込んでも構わないのですが、 CGI::Sessionのディストリビューションではあなたが継承し、そのオブジェクトにおけ るデータをシリアライズ化し、格納するためのfreeze()メソッドを呼び出すことが できるいくつかのライブラリを提供しています: CGI::Session::Serialize::Default CGI::Session::Serialize::Storable CGI::Session::Serialize::FreezeThaw Example: 例: freeze($data) ]]> 今、$storable_dataはディスクへ安全に保存することができます。 ドライバがディスクからデータを取得するために尋ねられる際には、シリアライズ化 されたデータはデシリアライズされるべきです。前述のシリアライザはthaw()メソッド も提供しており、１番目の引数としてデータをシリアライズ化されたデータを渡すと 保存される前の形でPerlのデータ構造を返します。例: thaw($stored_data); ]]> ドライバはもう一つのPerlライブラリで、CGI::Sessionを基底クラスとして用い、 以下のメソッドを提供することが要求されます: retrieve($self, $sid, $options) retrieve()はディスクからデータを取得する際に上記3つの引数を伴いCGI::Sessionに よって呼び出されます。$selfはセッションオブジェクトで、$sidはセッションid、 そして$optionsはハッシュのリファレンスの形で引数の一覧をnew()に渡すのです。 メソッドはアンシリアライズ化されたセッションデータを返すか、さもなくば失敗を 示すundefを返すべきでし。もしエラーが発生した場合、die()を呼んだりcroak()を 呼ぶ代わりにerror()にエラーメッセージをセットし、undefを返すことを提案 します: {FileName}, O_RDONLY) ) { $self->error("Couldn't read from $options->{FileName}: $!"); return undef; } ]]> もしそのドライバが存在しないセッションを要求した場合は、なんらかのエラーメッセージを生成するべきではなく、単純にundefを返すべきです。このことによってCGI::Sessionが新たなセッションidを作ることを通知することができるでしょう。 store($self, $sid, $options, $data) store()はセッションデータが格納されることが必要になった際CGI::Sessionによって 呼び出されます。格納されるためのデータは3つ目の引数としてメソッドに 渡されます。その引数はハッシュへのリファレンスです。成功を示す真の値 返すか、それ以外のケースではundefを返すべきです。エラーメッセージはerror()に 渡されるべきです。 remove($self, $sid, $options) CGI::Sessionがdelete()メソッド経由でディスクからセッションデータを消去するよう 要求された際、remove()は呼び出されます。成功の場合真を示す値を、それ以外の時は undefを返し、エラーメッセージはerror()に設定されるべきです。 teardown($self, $sid, $options) セッションオブジェクトが破棄されようとしている際にclose()経由で明示的に、 さもなくばプログラム中断時に暗黙的に呼び出されます。 CGI::Sessionはgドライバにenerate_id()メソッドを提供することも要求し、それは 新たなセッションのためのidを返します。繰り返しますが、自分自身で車輪を再発明 することは歓迎されます。しかし、覚えておいてほしいのですが、CGI::Sessionの ディストリビューションには対となる２つのgenerate_id()を提供するライブラリが 含まれます。あなたは単純にそれらを継承すべきです。以下に挙げるIDジェネレータ が使用可能です: CGI::Session::ID::MD5 CGI::Session::ID::Incr さらなる詳細を知るには各マニュアルを御参照下さい。 あなた独自のスタイルのidを用いたい場合、あなたはgenerate_id()メソッドを 上記ライブラリの継承を行うこと無しに明示的に定義することが可能です。 もしくはあなた独自のCGI::Session::ID::YourIDライブラリを書き、 session idを返す"generate_id()"メソッドを簡潔に定義し、それから DSNを構成する１部としてコンストラクタにその名前を与えて下さい。 Attributes}); ]]> あなたのCGI::Sessionディストリビューションは ともにあなたのドライバのための出発点として使用される Session/Blueprint.pmファイルともに配付されることになります。 freeze($data); ]]> thaw()メソッドを用いてシリアライズ化されたデー # タを復元します ]]> 上記の空白を埋めることで、あなたは "Value"}); ]]> とすることがき、後はCGI::Sessionのマニュアルにある通りです。 Copyright (C) 2002 Sherzod Ruzmetov. All rights reserved. This library is free software. You can modify and distribute it under the same terms as Perl itself. Sherzod Ruzmetov <sherzodr@cpan.org>. 提案、コメント及びパッチは歓迎します。 CGI::Session - CGI::Sessionマニュアル CGI::Session::CookBook - 実生活における実践的な解決方法 RFC 2965 - "HTTP State Management Mechanism" はftp://ftp.isi.edu/in-notes/rfc2965.txt で見付けることが可能です。 CGI - 標準のCGIライブラリ Apache::Session - もう一つのCGI::Sessionに対する素晴らしき選択肢 三浦真磁<snj@users.sourceforge.jp>