元スレ【PHP】セッションについて語ろう！【PHP】

php覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

102 = :

テストに使用してるブラウザは？
IEでプライバシーポリシーうんにゃらで2chからのクッキー食べてくれないとか・・

106 :

今やったらセッション使えなかったよ
なんやねんな

109 = :

>>108
ちゃうちゃう。
最終的なユーザのことを考えた場合のチェックとしてはIEは外せないけど、
デバッグには向かないから使うなってこと。JavaScript系は特にデバッグしにくい。
但しJavaScriptの挙動はIEとMozillaは違うので、そこは留意しないと駄目。
XMLのチェックの部分では、IEの方が出来がいいと思う。

110 = :

そうだね～
XMLはIEの方が良い！
Mozillaのデバックコンソールってもう一声どうにかならんかなぁ
あとあと、CSSで幅の定義を１どっとずれて描画するのもどーにかならんかなぁ
はうっ！セッション関係無いし

112 = :

　セッションとは、　　　フラグである・・・

　ようやく気が付いた。

113 :

>>112
セッションなんて言うからよく分からないんだよな。

「ページを超えて持ち運ばれるフラグ」って言えば分かり易いね。

115 = :

>114
セッションという機能がどういう風に実現されてるか、
またはどういう風にすれば実現出来るか考えてみれ

PHPのセッション機能は複数サーバ間で持ち越しすることは想定されていない（はず）なので、
書いてるようなことを実現したいなら、自分でセッション周りを作って、
セッション管理用のサーバを一つ用意すればいい。
が、そんなややこしいことするよりも、もっとスマートな解決法があると思うぞ。
根本的なとこから見直した方がいいと思う。

116 = :

>114
DBは使わないの？
方法によっては簡単に出来るのに。

119 = :

「ページを超えて持ち運ばれるフラグ」ってログイン後はhiddenで、一時的に生成されたユニークなIDみたいなの物をフォームに混ぜて本人確認しているってこと？？

perlでもできるよね。登録パスワードをフォームに混ぜちゃえばいいわけだし。
でもリファラー吐くブラウザだと他のサーバー行ったときにパスワードが入っているとまずいのか？？
だから一時的な物を生成するの？

120 = :

>>119
セッションはサーバーサイドでデータを保持するのが最大の特徴

「クッキーの逆のもの」と考えてもいいかも
クッキーもセッションも「ページを超えて持ち運ばれるフラグ」には違いないが、
そのデータそのものをどちらに保持するかが違う
クッキーはクライアントで保存し、データそのものを含む
だけどセッションの場合にはデータを保持するのはサーバー側で
クライアント側ではデータそのものは保持しない
（代わりにクライアントを識別するためのセッションＩＤを保持する必要はあるが)
POSTでhidden使って渡すのも、さらにGETでURI渡しするのも、
ページを超えて運ばれるフラグには違いないけど、これらも結局は
クライアント（ブラウザ）でデータを所持しているんだよね

121 = :

>>120
何かまとまってないぞ（笑）

要するに毎回データそのものをクッキーなりHIDDENフィールドなりで
運ぶという方法と
そうではなく、識別情報だけをクライアントとサーバー間で往復させて、
サーバー側にハッシュテーブルのようなものでデータを預けて置くという方法
の２つがある。

ぶっちゃけそれだけ。

122 = :

>>121
書いているうちに訳分かんなくなっちゃったｗ
最初の1行だけで済ませばよかったかな

127 = :

はてさて、cookieに限定したセッションの話かしらん

131 = :

言われただけの情報で結論出してセンスねえな～、想像力ゼロか？
それでカッコイイと思ってんのか？キモイ奴だな。

php使ってんならJS使わなくてもリファラからファイル（スクリプト）名と
必要ならクエリだけ取り出してリンクさせたらセッションも生きたままで
可変式のBACKボタンが生成できるだろ？

もっとも同一ドメイン内での話だけどな。

132 = :

>>59
亀レスだけど、目から鱗。今日悩んでいたことが氷解した。
解説書に書いてあることが間違ってたよヽ(`Д´)ﾉ
とにかく、一言言わせてくれ。どうもありがとう。

133 = :

ssl通信下でのみsessionＩＤをクライアント・サーバ間でやりとりする形で無い限り
セッションハイジャックの危険性は常につきまとうと思うのだが、
PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
良いと思うが、携帯サイト等でsidをURLに引き連れまわす必要がある場合
全ページsslで通信という形にするしかないと思うのだが、どうしてる？

136 = :

>>136
PCの場合はCookieオンリー前提で書いてました。説明不足すんません。
携帯は端末とプロキシのIPは一対一対応だと思ってたんだけど、もしかして違います？
（IPアドレス自体はセッションごとに変わりますが）
だったらこの方法は使えませんね。う～ん。

現行の3G携帯（というか、そのサーバー）はFOMAを除いてCookieに対応してますが
シェア最大のドコモがこれでは将来的にも難しいですね・・・。

個人情報など、重要なデータをセッションで使うときは最初から最後までSSLで通信して、
漏れてもあまり困らないデータは普通にセッションを使うしかないのかな。
Amazonなんかはそうなってるみたいですね。

139 = :

結局、全てをSSLで通信しないとセッションハイジャックは防げないということでFA?

140 = :

あてずっぽう

142 = :

　　　　　　　　　　　　　　防げ

144 = :

基本的なことでスマンがセッションって何？

148 = :

サーバー側に保存されるんだよね？
セキュリティ的にはどうなんだろう？