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

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

>>104
IEだけで動作チェックするのは間違い。

IEだけでしか使わない社内用とかならあり
んでも、Mozilla使った方が開発はしやすいぽ

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

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

>>110 ごめん名前間違えたｗ

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








　ようやく気が付いた。

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

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

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

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

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

つーかJavaみたいにphp5ではクラスにセッション情報を保持できるようになるんでしょうか？

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

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

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

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

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

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

ぶっちゃけそれだけ。

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

>>119
サーバ側で生成したサーバ側でしか利用しない値は、
わざわざhiddenで引き回したりしない。つか、してはいけない。
セキュリティホールにもなりうるし。

そういう用途のために(サーバ側の) session を利用するという理由もある。
情報の分離(隠蔽)だな。

session_register("session_a");
$b=array(1,2,3);
$session_a[b]=$b;

として

session_start();
unset($session_a);

しても$session_a[b]が消えてなかったんだが、バグですか？


PHP Version 4.3.3です。

バグと言うか、仕様じゃないの？

session_unregisterの注意を読むと、
unsetではフォーカス内の変数のみを消去して、
セッション内の登録は継続されるようだから、
セッションを再開した時にセッション内の登録変数を読み出し直すだけでは？
つまりそのunsetは現在の$session_aを削除するだけで、
$_SESSION['session_a']は削除しないんではないかと。

つーか、
$session_a['b']=$b;
って書くべきだし(typo?)、
session_(un)registerは非推奨

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

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

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

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

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

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

>>134
携帯サイトでクライアントをIPで判断できないでしょ？
キャリア側のプロキシのIPだらけになるのでは？
PCサイトの場合でもIPでの判断だと、NATの内側のクライアントは一纏めにしちゃうの？

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

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

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

>>133
まず前提からして間違ってる。

>PCサイトならばcookieにsidを食わせて、sidの確認が必要なページのみsslで通信すれば
>良いと思うが

良くない、cookie値はglobal変数「$_REQUEST」として常にサーバへ渡っている。
したがって、cookieに設定したセッションIDを必要とする時のみSSL通信下で行っても、
それ以外のページではsidは平文でネットワークを流れる事になる。

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

あてずっぽう

　　　　　　は、

　　　　　　　　　　　　　　防げ

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

セッションってどこに保存されるの？

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

>>148
レン鯖でもセーフモードかCGI+suEXECでsession.save_pathを適切に設定してれば大丈夫。
ちなみにメモリやデータベースにセッションを保存するようにもできる。
http://jp.php.net/manual/ja/function.session-set-save-handler.php

ただ、PHPはセッションIDにcookieを使う際にsecure属性をつけられないので
個人情報を扱うようなときはセッションを使うドメイン全体をSSLで保護するか
$_SESSIONを使う代わりにIDの発行からデータの出し入れまで全部を独自に管理しないといけない。