回答編集履歴
1
回答の意図について追記
answer
CHANGED
|
@@ -2,4 +2,34 @@
|
|
|
2
2
|
ただ、わざわざ自前でセッションの再発明をするのは色んな意味で望ましくないので、
|
|
3
3
|
そのフレームワークが対応してるならセッションのバックエンドをDBにするのが良いでしょう。
|
|
4
4
|
|
|
5
|
-
なお、セッションの生存期間は別にブラウザの状態とは関係ないですよ。
|
|
5
|
+
なお、セッションの生存期間は別にブラウザの状態とは関係ないですよ。
|
|
6
|
+
|
|
7
|
+
--以下追記
|
|
8
|
+
もういうべきことは他の方がおっしゃっているので蛇足感はありますが、
|
|
9
|
+
何をするべきかとその理由について一応追記させていただきます。
|
|
10
|
+
|
|
11
|
+
・やるべきだと思われること
|
|
12
|
+
自前のセッションもどきな仕組みはやめて
|
|
13
|
+
言語の提供するセッションの機能を適切に使用することに注力するべきと考えます。
|
|
14
|
+
私はあまりPHPに明るくないので公式ドキュメントを案内させていただきます。
|
|
15
|
+
[セッション処理](http://php.net/manual/ja/book.session.php)
|
|
16
|
+
|
|
17
|
+
バックエンドをDBにするなら以下の内容を使用することになると思われますが、
|
|
18
|
+
言い出しておいてなんですがそもそも本当にDBにするべきなのかについてはよく考えて選択なさってください。
|
|
19
|
+
[カスタムセッションハンドラ](http://php.net/manual/ja/session.customhandler.php)
|
|
20
|
+
|
|
21
|
+
・なぜそう思うか
|
|
22
|
+
Web上のアプリが特定のクライアントを識別し状態を保持するための仕組みがSession(とCookie)です。
|
|
23
|
+
あなたのやろうとしていることも特定のクライアントを識別し状態を保持するための仕組みですね。
|
|
24
|
+
要するにあなたが現在セッションとCookieとDBで自前でやろうとしていることはセッションの劣化コピーです。
|
|
25
|
+
本来の機能の上に劣化コピーをのっけようとしているのですから、片方は無駄に思えて当然といえば当然です。
|
|
26
|
+
|
|
27
|
+
ただし、上記ドキュメントを見ればわかりますが、
|
|
28
|
+
言語の提供しているセッションは適切に運用するために様々な機能を保有しています。
|
|
29
|
+
それらの機能を捨て自前の実装で済ませることは、
|
|
30
|
+
短期的には楽かもしれませんが実に多くのリスクを背負うことになるでしょう。
|
|
31
|
+
|
|
32
|
+
・盗聴について
|
|
33
|
+
当然HTTPであれば通信経路上にいる者はCookie（以外もですが）を盗聴できます。
|
|
34
|
+
しかし、適切に構築されたHTTPSな環境であれば盗聴は基本的に不可能です。
|
|
35
|
+
余計な仕組みを無駄に入れることを考えるのではなく、守るべきレイヤで守りましょう。
|