 |
|
| SledgeによるWebアプリケーションフレームワーク入門 |
第２回：セッション管理
著者：ライブドア 谷口 公一 2005/6/15
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| セッション情報の管理手法
|
Webアプリケーションを実装するにあたり、いくつかの開発言語には、開発言語自体に標準的にWebアプリケーション向けの「セッション操作」をするための機構が取り入れられているものもあります。
そうでない言語の場合は、その言語用として作られたWebアプリケーションフレームワークに、透過的にセッション操作を行なえるようにする機構が含まれていることがほとんどです。
ほとんどの言語やWebアプリケーションフレームワークでは、ユーザ側にSession IDのみを送り、Session IDに紐付く情報はアプリケーションから参照できるストレージやメモリ等の保存領域に確保されるようなしくみになっています。
|
| Sledgeにおけるセッション管理
|
ライブドアが開発を行なっているWebアプリケーションフレームワークである「Sledge」におけるセッション管理はどのような手法で行なわれているか、具体的に見てみましょう。
まずSledgeはPerlという言語によって開発されています。PerlはWebアプリケーション開発において柔軟に活用できる言語であるという点では、世界中でWebアプリケーション実装の際に愛用されている言語です。しかし本来Perlは「Webアプリケーション向け」に開発された言語ではないので、言語自体にはWebアプリケーションに特化した機能はまったく組み込まれていません。
そのためSledgeでは、Storable（http://search.cpan.org/dist/Storable/）というモジュールを利用して、セッションとして保存したい情報をシリアライズし、MySQLのDBに保存するようなしくみを標準的に備えています。そして、別のHTTPのトランザクション（画面遷移）先において保存されたデータを再利用する場合、保存されたデータをデシリアライズし、容易に再利用することができるようになっています。
もちろん、Session IDの発行、受け取り、セッション情報の保存、保存されたセッション情報の取得という、セッション管理に必要な処理は内部的に行なわれていますが、開発者はそれを気にすることなく容易にセッションを利用することができるようになっています。
Sledge::Pages::Baseを継承したクラス上から、session()というアクセサ経由でセッションを容易に利用することができます。
一般的なユーザ情報の入力フォームを例に取ってみましょう。「input」という入力フォーム、「confirm」という確認画面、「finish」という完了画面の順で3ページ構成の場合を例にします。
通常はHTTP GETでinput画面、そこからHTTP POSTでフォームと同じinput画面にパラメータを送り、その値をセッションに保存してconfirm画面にリダイレクト、そこから更にHTTP POSTで送られたデータをデータベースに保存した後、finish画面にリダイレクトする、という画面遷移が一般的ではないでしょうか。
この際、3画面のように見えますが、HTTPのトランザクション自体は以下のように5回発生します。
- GET input
- POST input
- GET confirm
- POST confirm
- GET finish
（2）から（3）へ、（4）から（5）へは、内部処理直後にリダイレクトという順で遷移するため、ユーザには3画面に見えます。
（2）で受け取ったユーザ入力パラメータのうち、名前（name）とメールアドレス（email）を（4）でデータベースへ保存するための実装例は下記のようなものになります。
|
sub dispatch_input {
my $self = shift;
# do something ...
}
sub post_dispatch_input {
my $self = shift;
my $input = {
name => $self->r->param('name'),
email => $self->r->param('email'),
};
$self->session->param(user_input => $input);
$self->redirect('./confirm');
}
sub dispatch_confirm {
my $self = shift;
my $input = $self->session->param('user_input');
return $self->redirect('./input') unless $input;
# do something ...
}
sub post_dispatch_confirm {
my $self = shift;
my $input = $self->session->param('user_input');
return $self->redirect('./input') unless $input;
# $input の情報を保存
$self->redirect('./finish');
}
sub dispatch_finish {
my $self = shift;
# do something ...
}
|
HTTPトランザクション上では途切れているpost_dispatch_input()とpost_dispatch_confirm()において、post_dispatch_input()で保存されたセッション情報がpost_dispatch_confirm()で再利用できるようになっています。
都度、「user_input」という名前のセッション情報をチェックしているのは、Webアプリケーション開発側の意図とは異なる経路でその画面に遷移して来た場合に、不正な経路と見なし、入力フォームに引き戻す必要があるためです。
また、post_dispatch_input()内で、セッションに情報を保存する前に、データの妥当性や汚染のチェック（validation）を正しく行なっておくことにより、データベースに保存する時点でセッションに保存されている情報は既にチェック済みの信頼できるデータであることがわかるため、そのままデータベースに保存することができます。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
株式会社ライブドア 谷口 公一
テクニカルディレクター。専門知識が全く無い中、オープンソースソフトウェアやコミュニティからシステム開発の知識やノウハウを習得し、オープンソースコミュニティにおいて活発に活動を行っている同社に憧れて入社。現在はポータルサイト「livedoor」におけるサービス開発を行う一方、本業の傍ら、お世話になっているオープンソースコミュニティへのコントリビューションも行なっている。
|
|
|
|
|
|
