2006年11月20日

セッションを考える。その2 .htaccessに頼る。

Apacheのモジュールとして動くと言うことがPHP使用の最大の理由だが
モジュールモードだとsafemodeということで使えない関数も多い。
しかし.htaccessでほとんどどうにかなる事を知った。
セッションを扱うに当たっては保存場所を

session_save_path("/SES1");

のようにしたかったのだがこのsession_save_pathも使用禁止だった。

だから初期段階では「どこか」にセッションデータは収納されているようだったが
自分の領域でなく気持ち悪かった。

変更について以下の二つの方法がある事を知った。
特にこれはxreaでの設定例になる。

  1. PHPの中にini_set命令を入れる。

    ini_set( 'Sessions.Save_Path' , '/virtual/ユーザー名/ディレクトリー' )



  2. .htaccessの中で設定する。

    php_value session.save_path /virtual/ユーザー名/ディレクトリー


どちらの例でも正常に動いた。
ようするにphp.iniはモジュールの場合再起動しないと有効にならないから
共用サーバーでは変更できないけれど
PHP_INI_SYSTEM」でない「PHP_INI_ALL」や「PHP_INI_PERDIR」のものは
.htaccessかini_setで変更可能だということだ。
そのパラメータがそのディレクトリーにあるPHPプログラムで使われるのならば
なにもrequireなどせずに.htaccessに記述すればいい。

今回の場合は

php_value session.save_path /virtual/ユーザー名/ディレクトリー
php_value session.name SES1
php_value session.cookie_lifetime 3600

などと追記することでメインコードは減らすことができる。
そういう見方からすると今まで悩みの種だった。
「取り合えずリクエスト攻撃」も post_max_sizeでファイルリミットなどを低くするなどで対応できる。

requireで初期化とini_setを使うのと.htaccessを使うのとどちらがベターかわからないが
ケースバイケースだろうと思った。
しかし変更の本来の理由はセキュリティだが実のところ
デフォルトにしろ変更後にしろ外部からアクセスはできないから
あくまでファイルをコントロールできるところに置くという事だけに意味がある。

但し今日の段階ではできたセッションファイルはオーナーがapacheなので
削除はできてもFTPでダウンロードできない。

あとブログなどのように明示的にユーザーが事前登録されているものは
元々1対1のデータベースに「ログイン時のユニーク変数」を登録して
そちらからキーサーチした方がよいだろうし

ページ遷移であればFlashを使い、ユーザーデータは極力shared Objectに入れる形にすれば
サーバーサイドでデータ保持をする理由もない。

またクッキーの寿命が切れてセッションがリセットされるのにガベージコレクションの対象にならないと言うのも
無駄なファイルを生むだけで問題だ。

そう考えるとセッションのクッキーのライフタイムは長い目にして
明示的にセッション破棄するようにしたほうがいいと感じた。
あるいはFlash ベースの場合はクッキーを使わない方が良さそうだ。
またクッキーを使う場合はまずクッキーのチェックをしてSIDのフェイクに対応する手も検討。

具体的にセッションの使用を考えているのは
あくまでhttpベースでユーザーを信用しないと言う前提での継続的接続であって
ある意味前回のソケットと概念は近いが
使いやすいものを構築すると結局もう少しデータベースメインになるか
よりシンプルなものの方が良いと思う。

Flashなどでどうしても2セッションになるようなもの
例えば画像やファイルをアップロードして
その結果をファイルとして戻したりその後のレスポンスでダウンロードするようなものが考えられる。
セッションを使うことでテンポラリーの混同は避けられるが
ガベージコレクションシステムなどなくてもユニークIDだけ出せれば
任意でファイルは削除できるのではないかとおもった。
問題はファイアップロードしたあと処理を完全に終わらせないケースが続くことで
の場合も独自に組み込まないのならばガベージコレクションの頻度を増すなどの手がなくもない。

同一人物のクッキー切れによる再アクセスも含めて
無駄なファイルを生成しないアルゴリズムをもう少しつめて
セッションをほんとに使うか別のアプローチにするかきめたい。

なんか取り留めないけれどチュートリアルとかデモではなくて実験しながらの進歩だからいいのだ。
posted by Xo_ox at 22:58| Comment(5) | サーバーサイド手習い | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
はじめまして、こんにちは。
とても参考になる記事を有難うございます。

ところで、私、xo-oxさんと同じxreaサーバー(coreserver)を先日からお借りしたのですが、本記事を参考にしながら、.htaccess内に

php_value session.save_path /virtual/ユーザID/tmp
php_value session.name tmp

と記述したのですが、セッションに保存したキーが認識出来ない状態があるのです。

私のスクリプトが可笑しいのか、.htaccess内の記述が可笑しいのか、もしくはサーバーの状態が良くないのか困り果てている状態でして・・・。

コメント欄にて失礼かと思いましたが、ご意見頂戴したく投函させて頂きます。
以上、宜しくお願いいたします。
Posted by chap at 2008年03月23日 17:00
最近PHPいじっていないのでちょっと確信は無いのですが
頂いた情報ではあまりわからないのですが
私の記事をベースにしている場合
IPが変動しちゃうとセッションは無効になるようになっています。
あとは変数の命名とかセッションタイムとか
そうした要因があるかもしれません。
xrea固有要因もあるかもしれないので
xreaのサポートBBSに書き込むとレスが期待できるかもしれません。

あとサーバーは有料版を前提にこの記事は書いたので
無料版だと広告が入らないエリアを使わないとダメかもしれません。(頭にxがつくフォルダー?)

参考にならないレスですみません。
3Dが一段落したらまたサーバーサイドをやり直して見ます。
Posted by xo-ox at 2008年03月23日 19:41
こんにちは。ご丁寧なお返事をありがとう御座います。
ご挨拶が遅れて申し訳ありません。

あれから、.heaccess内の記述を変えてみたり、色々しておりますが、途中でセッションが切れると、一向に改善出来ずにいる次第です。


>だから初期段階では「どこか」にセッションデータは収納されているようだったが
>自分の領域でなく気持ち悪かった。

そうですね。気持ち悪いという表現そのままですよね(笑)。
しかし、デフォルトのままであれば、セッションが切れることなく快適?なのですが、保存場所の指定を行うと、セッションが切れる次第で・・・涙

いずれにしても、過去の記事のコメントに、ご丁寧なお返事を頂戴し感謝いたします。
ありがとう御座いました。



Posted by chap at 2008年04月07日 15:37
もう見てないと思うけれど

結局セッションというのは結構PHP内部の適当な実装だし
セキュリティを考えるとIPとかクッキーのチェックはどのみち必要で管理するわけだから
それをやるくらいならば
PHPのデータベースオブジェクト(内容はSQLiteかMySQL)
ないしはSQLiteかMySQL直で
アクセスがあったときにリスト変更が必要な時間を作っておいて
次に呼び出しがあって操作があったときに
その時間になっていたら削除処理するとかの方が
自分としてはいいかなという結論に達しました。
Posted by ×○_○× at 2008年04月08日 09:40
こんにちは!
お礼のあと、ご意見も頂戴していたのですね・・。ありがとう御座います!

セキュリティって奥が深いですよね・・ご意見を頂戴し、新たに視野が広がった気がします。ありがとう御座いました!
Posted by chap at 2008年05月09日 17:55
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。