CGI-Session-3.11 > Tutorial

CGI-Session-3.11

名前
状態メンテナンスの大要
プログラミングスタイル
最初にあなたが知るべき事
新しいセッションの作成
セキュリティ
- 格納
- SESSION ID
ドライバに特化した事項
著作権
作者
参考文献
翻訳者

名前¶

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のクエスチョンマーク(?)に続く文字列です。

    http://my.dot.com/login.cgi?user=sherzodr&password=topSecret

おそらくあなたは既にこの解法を使っていたのではないかと思われます。クエリ文字列でも別の場所へのクリックによって状態を渡す助けになりますが、あなたはどれだけ安全なものかと言うことを考えていますか？これらの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'スイッチを導入しました:

    use CGI::Session qw/-api3/;

これによってライブラリに新しい文法を使うことを伝えるのです。しかしライブラリの最新リリースでは、それを自動的に探知するでしょう。つまり"-api3"スイッチをもはや呼び出す必要が無くなるのです。あなたが古い2.xのapiをもう使わないというならば、我々にそのことを尋ねるのはどうかお止め下さい。我々はあなたに何も教えないでしょう。

しかし本ライブラリを使い始める前に、どこにどうやってセッションデータをディスクに保存するのかを決断する必要があるでしょう。言い替えればどのドライバを使うのかを伝えなければなりません。あなたはデフォルトでディストリビューションに搭載されている"File", "DB_File"及び"MySQL"ドライバのいずれかを選択することが可能です。このドキュメントでは要求するものがもっとも少ないため理解しやすい"File"ドライバを用いた例を示します。実行するには次のようにセッションオブジェクトを作成して下さい。

    use CGI::Session;
    $session = new CGI::Session("driver:File", undef, {Directory=>'/tmp'});

一つ目の引数は呼び出されるデータソース(略してDSN)の名前です。undefであれば、ライブラリはデフォルトのドライバ、「File」を使用するでしょう。よって、下記の例のようにドライバに関しては明示的に示す代わりにこのように表現することも可能です:

    $session = new CGI::Session(undef, undef, {Directory=>'/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()に未定義の値を２つ目の引数に渡すだけで構いません。

    $session = new CGI::Session("driver:File", undef, {Directory=>"/tmp"});

ディレクトリはセッション分散したファイルの形で格納されるであろうファイル及びそのロックの場所を示します。セッションオブジェクトを生成する際には私が上記に示したことをするために、次の手順が踏まれるでしょう:

あなたのためにセッションIDは生成され
あなたが指定したディレクトリ中からidによって格納されたファイルが連想されます。

これからは、あなたが新しく生成されたセッションidにアクセスしたい場合はただこうすれば良いのです。

    $sid = $session->id();

クッキーとして送信される、あるいはクエリ文字列やフォーム内の隠しフィールドとしてそのまま用いられることが可能なa983c8302e7a678a2e53c65e8bd3316と言った文字列を返します。

    $cookie = $cgi->cookie(CGISESSID => $session->id);
    print $cgi->header( -cookie=>$cookie );

もし上記の方法が無理であれば、CGIの詳細を御覧下さい。

既存のセッションを初期化する¶

ユーザーが他のリンクやちょっと間を置いてサイトを再訪問した際、我々は再び新しいセッションを作成しなくてはならないのでしょうか？もちろん違います。これではセッションの維持と言う目的を打ち負かしてしまうことになるのですから。我々がクッキーとして既にidを送信していたら、我々が皆必要とするものはセッションオブジェクトが生成されている間２つ目の引数としてそのidを渡すことのみです。

    $sid = $cgi->cookie("CGISESSID") || undef;
    $session    = new CGI::Session(undef, $sid, {Directory=>'/tmp'});

下記の文法ではまずはじめに既存のセッションデータを初期化しようとし、もし新しいセッションファイルを生成する場合(セッションが存在しない場合)でも、我々が意図した結果となります。しかし、もしユーザーがクッキーをサポートしていない場合はどうなるのでしょうか？その場合我々はクエリ文字列として全ての urlに追加する必要があります。クッキーを追加する方法を御覧下さい:

    $sid = $cgi->cookie('CGISESSID') || $cgi->param('CGISESSID') || undef;
    $session = new CGI::Session(undef, $sid, {Directory=>'/tmp'});

あなたがCGIオブジェクトの扱いに長けていると仮定して、上記の２行を１行に納めることが可能です:

    $session = new CGI::Session(undef, $cgi, {Directory=>"/tmp"});

もし２つ目の引数として文字列の代わりにオブジェクトを渡すと、CGI::Sessionはクッキーあるいはクエリ文字列からセッションidを取得しようと試み、適宣にセッションを初期化します。クッキー及びクエリ文字列のパラメータはデフォルトで CGISESSIDであると仮定します。この設定を変更するためには、CGI::Session あるいはそのオブジェクトのうちいずれかのname()クラスメソッドを呼び出す必要があるでしょう:

    CGI::Session->name("MY_SID");
    # 又は

    $session->name("MY_SID");

    $session = new CGI::Session(undef, $cgi, {Directory=>'/tmp'});

セッションにデータを格納する¶

param()メソッドを用いてオブジェクト内に値を一つ格納するためには:

    $session->param("my_name", $name);

あなたは配列や、ハッシュやオブジェクトなどのような複雑なデータを格納するために param()メソッドを用いることが可能です。配列及びハッシュを格納する際は、リファレンスとして渡さなければなりません:

    @my_array = ("apple", "grapes", "melon", "casaba");
    $session->param("fruits", \@my_array);

同様にオブジェクトも格納することが可能です:

    $session->param("cgi", $cgi);   # CGI.pmオブジェクトを格納します

あなたが望むセッションオブジェクト内にCGIのパラメータを全て格納する方法も存在します。あなたはセッションオブジェクトに各フォームの要素からのあなたは後で多数のクエリパラメータを格納しなければならないためににこの形式を望むことだと思われます。以下の文法を御覧下さい:

    $session->save_param($cgi, ["keyword", "category", "author", "orderby"]);

save_param()は上記の全CGIパラメータをセッションオブジェクトに格納させるでしょう。これは以下と同様のことを言っています。

    $session->param("keyword",  $cgi->param("keyword"));
    $session->param("category", $cgi->param("category"));
    # など全てのフォーム要素に対して

全CGIパラメータを保存したい場合ですが、save_param()の２つ目の引数を省略するだけです:

    $session->save_param($cgi);

上記の文法は全ての使用可能/アクセス可能なCGIパラメータを保存します。

保存されたデータへのアクセス¶

もしあなたがデータにアクセスできないならば、保存されたデータに接点がないのです。あなたは一度データを保存するのに用いた同じparam()で保存されたデータにアクセスすることが可能です。

    $name = $session->param("my_name");

上記のparam()の形式では"my_name"として過去に保存されたセッションのパラメータを取得します。過去に保存された@my_arrayを取り出すには:

    $my_array = $session->param("fruits");

配列へのリファレンスが戻って来るでしょう。そして、@{$my_array}として参照する事が可能です。

あなたはユーザーの好みや以前のアクションに応じた入力済、あるいは選択済のラジオボタンやチェックボックス、ドロップダウンメニューなどのフォームをとても頻繁に作らなくてはならないだろうことにお気づきであると思われます。 textやtextareasならそれほど大したことではありません: 単に一つのパラメータをセッションから取得し、textフィールドにハードコーディングすれば良いのですから。」しかしラジオボタンやチェックボタン、スクロールするリストのグループを扱うとき、あなたはどうするでしょう？この目的のため、CGI::Sessionはload_param() メソッドを提供しており、CGIオブジェクトに与えられたセッションパラメータを読み出します (save_param()メソッドあるいはその他の選択肢で過去に保存されていると仮定して):

    $session->load_param($cgi, ["fruits"]);

さて、CGI.pmを使って選択済のチェックボックスを生成するには:

    print $cgi->checkbox_group(fruits=>['apple', 'banana', 'appricot']);

もしあなたがHTML::Templateを用いることでスキンからコードを分離させる場合、 HTML::Templateを用いてCGI::Sessionオブジェクトをassociateすることによって同様のことが可能になります。我々はこのトリックが大好きです。

    $template = new HTML::Template(filename=>"some.tmpl", associate=>$session);
    print $template->output();

HTML::Templateでassociateする間、セッションオブジェクトに"first_name"及び "email"パラメータが格納されていると仮定すると、"some.tmpl"ファイルを用いてそれらの値にアクセスできます:

    Hello <a href="mailto:<TMPL_VAR email>"> <TMPL_VAR first_name> </a>!

HTML::Templateによるさらなるトリックを知りたい場合はライブラリマニュアル (HTML::Template及びCGI Session CookBook。

セッションを閉じる¶

通常あなたは明示的にセッションを閉じる必要はありません。プログラムが終了するか、あるいはセッションオブジェクトがスコープからはずれた際、セッションが閉じられます。しかしながら時にはCGI::Sessionの<close()>メソッドあるいはオブジェクトを未定義にすることによってセッションを明示的に閉じたい場合があるかもしれません。セッションを閉じるとは一体全体何なのでしょう？ - あなたは尋ねるでしょう。セッションがアクティブな間、ディスク内のセッションオブジェクトの更新がすぐに行われるわけではありません。flush()メソッドでバッファをフラッシュさせると言う選択肢をとるかあるいはプログラムを終了させるかあるいはclose()メソッドを明示的に呼び出してセッションを破棄するまではメモリ内に保存されます。

状況によってはセッションを閉じたいもののプロセスをしばらくの間終了させたくない場合もあるかと思われます。おそらくそのようなケースはGUI及びデーモンアプリケーションによるものであると思われます。この場合close()こそがあなたが求めていたものなのです。Note: 我々はclose()よりもシンプルな開放用のメソッドを好みます。 (close()は機能面で劣ります。)

    undef($session);

もしあなたがセッションをオブジェクトを何らかの理由でバッファ内のデータとディスク内のデータを同期させたいならば、flush()こそあなたの求めるものです。

Note: close()も同様にflush()を呼び出します。したがってclose()を呼び出す前に flush()を呼び出す必要は全く無いのです。

セッションデータのクリア¶

セッションデータを保存し、セッションデータにアクセスすると、ある時点で全てでなくとも、特定のセッションデータをクリアしたくなるでしょう。この目的のためにCGI::Sessionはセッションパラメータをオブジェクトから消すべきパラメータ名を指示した配列のリファレンスの表現で引数を一つ取るclear()メソッドをオプショナルで提供しています。

    $session->clear(["~logged-in", "email"]);

上記の行ではセッションパラメータ"~logged-in"及び"email"をセッションから消去します。そして次にこうすると:

    $email = $session->param("email");

iundefが戻ります。もしclear()の引数を省略した場合、あなたが今までにセッションオブジェクトに格納したセッションパラメータが削除されてしまうのでお気を付け下さい。セッションそのものを消してしまうのではないことを念頭に置いて下さい。セッションはまだ開いていてアクセス可能です。中に格納されたパラメータが消去されただけなのです。

セッションを削除する¶

もし始まりが存在し、終わりが存在するならば。もしセッションが作らるならば、それはディスクから削除することが可能である方が良いに決まっています。

    $session->delete();

上記のようにdelete()を呼び出すことによってディスクからセッションを削除した方が好ましいと言えます。clear()と混同しないように、これは特定のセッションパラメータをクリアしますが、セッションは開いたままです。

期限切れ¶

CGI::Sessionはセッションデータの期限切れを実現するための限られた機能を提供します。セッションの期限切れはdelete()経由で消去することと同等ですが、削除は自動的に行われます。セッションを期限切れにするためには、ライブラリに最終アクセス時からどれだけ長く有効であるかを教える必要があります。時間が来れば、 CGI::Sessionはセッションを取得することを拒否します。そのことによりセッションは削除され、真新しいセッションが返って来ます。セッションに対する期限切れを示す時計を割り当てるためにはexpire()メソッドを用います。

    $session->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分間放っておくとクレジットカードへのアクセスの期限が切れると言った、階層化されたセキュリティ認証をシミュレートするのに用いることも可能です。

    $session->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"にあるので読みましょう。

SESSION ID¶

セッションidが簡単に推測されることはありません(Incr Idジェネレータを用いない限りは)!CGI::Sessionにおけるデフォルトの設定ではDigest::MD5はプロセスid、エポックからの秒数およびランダムな数字を用いて32文字長のダイジェストを生成します。しかしながらこの文字列は他人が推測することは不可能で、もし何らかの方法で見付けることができたとしても、他人の識別子を使うことなどできるのでしょうか？

あなたはただ誰かにemailかインスタントメッセージ経由でオンラインアカウントのプロファイルへのリンクを提供するところで現在ログインしていると言うシナリオを考えてみましょう。あなたがその人に提供するURLはクエリ文字列の一部としてセッションidを含んでいます。もしそのサイトがセッションを初期化して、ただクエリ文字列のパラメータを用い、今サイトに現れた人があなたであることを示すリンクをクリックすると、ただちにあなたの機密データの全てにアクセスしたかもしれません。なんと恐ろしく無知な実装なのでしょう。セッションidを伴ったURLを貼り付けることが、事故が起こるのを待つようなものであることを知らないなんと哀れなお子様なのでしょう。

もしあなたが単にクッキーをセッションidの転送役として用いた場合でさえも、同じクッキーファイルの中に同じセッションidを伴うクッキーを植え込み、webブラウザに適切なセッションidをサーバーに送信するよう細工することは難しいことではないのです。よって、もし私達にセッションデータを取得するよう依頼している人が実際にセッションデータを最初に初期化した人であるかどうか、セキュリティ用のキーをチェックすべきです。CGI::Sessionではライブラリを「使って」いる間、 "-ip_match"スイッチを使用加納にすることによってこのようなケースにあなたが注意を注ぐことを手助けします。

    use CGI::Session qw/-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:

例:

    # $dataは格納される必要があるハッシュのリファレンスです。

    my $storable_data = $self->freeze($data)

今、$storable_dataはディスクへ安全に保存することができます。

ドライバがディスクからデータを取得するために尋ねられる際には、シリアライズ化されたデータはデシリアライズされるべきです。前述のシリアライザはthaw()メソッドも提供しており、１番目の引数としてデータをシリアライズ化されたデータを渡すと保存される前の形でPerlのデータ構造を返します。例:

    my $hashref =  $self->thaw($stored_data);

ドライバのメソッド¶

ドライバはもう一つのPerlライブラリで、CGI::Sessionを基底クラスとして用い、以下のメソッドを提供することが要求されます:

retrieve($self, $sid, $options)

retrieve()はディスクからデータを取得する際に上記3つの引数を伴いCGI::Sessionによって呼び出されます。$selfはセッションオブジェクトで、$sidはセッションid、そして$optionsはハッシュのリファレンスの形で引数の一覧をnew()に渡すのです。メソッドはアンシリアライズ化されたセッションデータを返すか、さもなくば失敗を示すundefを返すべきでし。もしエラーが発生した場合、die()を呼んだりcroak()を呼ぶ代わりにerror()にエラーメッセージをセットし、undefを返すことを提案します:

    unless ( sysopen(FH, $options->{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()経由で明示的に、さもなくばプログラム中断時に暗黙的に呼び出されます。

IDの生成¶

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を構成する１部としてコンストラクタにその名前を与えて下さい。

    $session = new CGI::Session("id:YourID", undef, {Neccessary=>Attributes});

設計図¶

あなたのCGI::Sessionディストリビューションはともにあなたのドライバのための出発点として使用される Session/Blueprint.pmファイルともに配付されることになります。

    package CGI::Session::BluePrint;

    use strict;
    use base qw(
        CGI::Session
        CGI::Session::ID::MD5
        CGI::Session::Serialize::Default
    );

    # これより下で必要なライブラリをロードします

    use vars qw($VERSION);

    $VERSION = '0.1';

    sub store {
        my ($self, $sid, $options, $data) = @_;

        my $storable_data = $self->freeze($data);

        #ここであなたは$storable_dataをディスクに格納する必要があります

    }

    sub retrieve {
        my ($self, $sid, $options) = @_;

        # あなたは格納されたデータを取得する必要があるでしょう。
        # そして$self->thaw()メソッドを用いてシリアライズ化されたデー
        # タを復元します

    }

    sub remove {
        my ($self, $sid, $options) = @_;

        # 単純にidより連想されたデータを消去する必要があります

    }



    sub teardown {
  
      my ($self, $sid, $options) = @_;

      # このメソッドはセッションオブジェクトが破棄される直前に呼び出さ
      # れます。

    }

    1;

    __END__;

上記の空白を埋めることで、あなたは

    $session = new CGI::Session("driver:MyDriver", $sid, {Option=>"Value"});

とすることがき、後はCGI::Sessionのマニュアルにある通りです。

著作権¶

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>