モジュールモードだとsafemodeということで使えない関数も多い。
しかし.htaccessでほとんどどうにかなる事を知った。
セッションを扱うに当たっては保存場所を
session_save_path("/SES1");
のようにしたかったのだがこのsession_save_pathも使用禁止だった。
だから初期段階では「どこか」にセッションデータは収納されているようだったが
自分の領域でなく気持ち悪かった。
変更について以下の二つの方法がある事を知った。
特にこれはxreaでの設定例になる。
PHPの中にini_set命令を入れる。
ini_set( 'Sessions.Save_Path' , '/virtual/ユーザー名/ディレクトリー' )
.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だけ出せれば
任意でファイルは削除できるのではないかとおもった。
問題はファイアップロードしたあと処理を完全に終わらせないケースが続くことで
の場合も独自に組み込まないのならばガベージコレクションの頻度を増すなどの手がなくもない。
同一人物のクッキー切れによる再アクセスも含めて
無駄なファイルを生成しないアルゴリズムをもう少しつめて
セッションをほんとに使うか別のアプローチにするかきめたい。
なんか取り留めないけれどチュートリアルとかデモではなくて実験しながらの進歩だからいいのだ。
とても参考になる記事を有難うございます。
ところで、私、xo-oxさんと同じxreaサーバー（coreserver）を先日からお借りしたのですが、本記事を参考にしながら、.htaccess内に
php_value session.save_path /virtual/ユーザID/tmp
php_value session.name tmp
と記述したのですが、セッションに保存したキーが認識出来ない状態があるのです。
私のスクリプトが可笑しいのか、.htaccess内の記述が可笑しいのか、もしくはサーバーの状態が良くないのか困り果てている状態でして・・・。
コメント欄にて失礼かと思いましたが、ご意見頂戴したく投函させて頂きます。
以上、宜しくお願いいたします。
頂いた情報ではあまりわからないのですが
私の記事をベースにしている場合
IPが変動しちゃうとセッションは無効になるようになっています。
あとは変数の命名とかセッションタイムとか
そうした要因があるかもしれません。
xrea固有要因もあるかもしれないので
xreaのサポートBBSに書き込むとレスが期待できるかもしれません。
あとサーバーは有料版を前提にこの記事は書いたので
無料版だと広告が入らないエリアを使わないとダメかもしれません。(頭にxがつくフォルダー？)
参考にならないレスですみません。
3Dが一段落したらまたサーバーサイドをやり直して見ます。
ご挨拶が遅れて申し訳ありません。
あれから、.heaccess内の記述を変えてみたり、色々しておりますが、途中でセッションが切れると、一向に改善出来ずにいる次第です。
>だから初期段階では「どこか」にセッションデータは収納されているようだったが
>自分の領域でなく気持ち悪かった。
そうですね。気持ち悪いという表現そのままですよね（笑）。
しかし、デフォルトのままであれば、セッションが切れることなく快適？なのですが、保存場所の指定を行うと、セッションが切れる次第で・・・涙
いずれにしても、過去の記事のコメントに、ご丁寧なお返事を頂戴し感謝いたします。
ありがとう御座いました。
結局セッションというのは結構PHP内部の適当な実装だし
セキュリティを考えるとIPとかクッキーのチェックはどのみち必要で管理するわけだから
それをやるくらいならば
PHPのデータベースオブジェクト(内容はSQLiteかMySQL)
ないしはSQLiteかMySQL直で
アクセスがあったときにリスト変更が必要な時間を作っておいて
次に呼び出しがあって操作があったときに
その時間になっていたら削除処理するとかの方が
自分としてはいいかなという結論に達しました｡
お礼のあと、ご意見も頂戴していたのですね・・。ありがとう御座います！
セキュリティって奥が深いですよね・・ご意見を頂戴し、新たに視野が広がった気がします。ありがとう御座いました！