【PHP】セッションについて語ろう！【PHP】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
03/09/24 19:31ID:SnRvXmpIブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん
0369367
2006/05/23(火) 15:03:01ID:???すみません、クッキーと書きましたが
ブラウザを閉じたら消えるやつで
いわゆるセッションと同じようなもののことでした。
でもブラウザの実装によっては
一時的でもクライアントに保存されるため
リスクが高いということでしょうか。
0370nobodyさん
2006/05/23(火) 20:46:03ID:???強いて言うなら、その方法だと、XSSでクッキーを盗まれたときに、
パスワードを変更しない限り、その情報が使えてしまうけど、
XSS心配したらセッションも使えないし、
リスクという点では大差ないと思う。
セッションには、
・PHPに初めから実装されていて、手軽に使える
・ブラウザを閉じるまでは、以前の情報を継続して使える
という利点があるけど、単にログイン状態を保存しておくだけだったら、>>367の方法でも良いんじゃないかな。
0371nobodyさん
2006/05/23(火) 23:07:03ID:???永続的なパスワードは一時的であれクッキーに保存するべきではない。
XSSでコッソリ取られた日には目も当てられない。
0373nobodyさん
2006/05/24(水) 15:21:01ID:8TTcDRX+10秒たってもセッションがタイムアウトしません。
なぜなんでしょうか？
環境はIIS5.0 / php5.0.3 です。
php.iniの値はこのようになってます。
session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn On On
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 100 100
session.gc_maxlifetime 10 10
session.gc_probability 1 1
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path no value no value
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies Off Off
session.use_trans_sid 0 0
0374368
2006/05/24(水) 15:58:59ID:???よくよめ。
>>371
確かに。XSSの事忘れてた。。
つーか、わざわざパス記録すんなよ。メリット無いだろ。
セッションならXSSで取られてもIPで再度チェックすれば大体防げる。
0375nobodyさん
2006/05/24(水) 17:26:05ID:???IPが変わる環境のクライアントは切り捨ててるの？
0376368
2006/05/24(水) 17:35:05ID:???ホスト名が取得出来るんだったら、末尾から数えて二つめのドットまでマッチングとかな。
自分はもうちょっと複雑に可変範囲決定してるが、方法はいくらでもあると思われ。
0377nobodyさん
2006/05/24(水) 18:12:48ID:???携帯サイトのことを言っているのならIPチェック自体がナンセンス
通常のネットワーク環境を前提にしているとしたらIPが変わった時点でセッションが切れて当然
0378nobodyさん
2006/05/24(水) 18:15:10ID:???苦情来ない？実際自分も不便だと思うからneverにしてる。
クリティカルなやりとりに入る場合は再入力させてるけど。
0380386
2006/05/24(水) 18:21:45ID:???いや、so-net.netとか。.ne.jpとかは末尾ドット二つじゃ足りなくて三つ遡ってマッチしなきゃならんが。
ヤフやらはてなやらアマゾンはそんな実装だな。>>378
関係ないけど、ヤフの会員登録(HTTP)は生でパス流してる。
0382386
2006/05/24(水) 18:23:41ID:???チャレンジレスポンスだけど、途中に割り込まれたらっつーのもあるし、今時HTTPって。。
0383nobodyさん
2006/05/24(水) 18:27:30ID:???所謂セッション管理についてのスレだから一行動としてのセッションで捉えなくて良いと思ふ、
つか、今時そんな短時間でログアウトさせてる方が珍しい、金融機関除いて
0385nobodyさん
2006/05/24(水) 18:43:29ID:???セキュリティ的には短い方が望ましいが、長い方が明らかに便利。
あ、良いこと考えた。
0386386
2006/05/24(水) 18:46:32ID:???直接PCを操作される場合のリスクを考えてﾅｶﾀ。何か良い方法無いですか？
0388nobodyさん
2006/05/24(水) 23:16:27ID:vQsxJJUNちゃんとセションファイルに書きこまれないときがあります。
具体的には
画面AでA.php?hoge=aで
$_GET['hoge']から'a'を取得し
$_SESSION['hoge']="a"といれ、
画面Bに行く。
このとき$_SESSION['hoge']はaとなっている。
ブラウザの戻るでAにもどり
URLにA.php?hoge=bと入力しエンターキー。
（$_SESSION['hoge']="b"となっているはず。）
画面Bに行く。
するとこのとき、
$_SESSION['a']の中には
aが入っていて、こちらの期待する値（b)になりません。
画面Aに戻り
URLにA?hoge=bと入力しエンターキーを押して
F5を押すと
$_SESSION['a']には期待値（b)が入っています。
どうしてこのようになるのか分かりません。
どなたか教えていただけないでしょうか。
また期待値を得るためにはどうしたら良いでしょうか？
0390388
2006/05/25(木) 00:15:44ID:wZM3F4wk↓こんな感じで書いてます。よろしくおねがいします。
top.php
<?
session_start();
$_SESSION['name'] = $_GET['name'};
print($_SESSION['name']);//ここでは表示される値は毎回更新されている
:
:
:
//入力へのリンク
print ("<a href ='input.php'>リンク</a>");
?>
input.php
<?
session_start();
print($_SESSION['name']);//←ここで値が更新されず、前の値がでることがある。
：
：
：
?>
0391nobodyさん
2006/05/25(木) 00:57:00ID:???別に問題なく動作したが。。。
動作がおかしいときは、ブラウザがキャッシュから表示してるのだと思う。
session_cache_limiterを弄ったりしてなければ、あまり起きないはずだが、
どうしても以前の情報を表示したくないのなら、
input.phpにランダムなクエリーをつけるか、POSTでアクセスするかかな。
0392nobodyさん
2006/05/25(木) 00:59:45ID:???それから、本当にキャッシュから表示してるのか確かめたければ、
input.phpに現在時刻の表示とかを入れると良いよ。
0393388
2006/05/25(木) 08:20:59ID:???どうもありがとうございます。
>input.phpに現在時刻の表示とかを入れると良いよ。
私もこれは試したのですが、
時刻は現在時刻を表示してるのですが
$_SESSIONの値は変わらずといった状態でした。
設定をもう一度見直してみます。
お世話になりました。
0394nobodyさん
2006/05/25(木) 08:36:41ID:???もしかしたらここの主旨とずれていたかもしれません。
質問用スレッドにて質問させて頂きます。
どうもすみませんでした
0395nobodyさん
2006/05/25(木) 16:05:42ID:???みなさんは自作されてるのでしょうか？
PEAR::Authを使ってるのですが
このスレを読んで心配になりました。
PEAR::Authのログインしたときのクッキーの送受信を
セキュアな接続のときに限定することはできないですよね？
0396nobodyさん
2006/05/26(金) 22:50:44ID:???ブラウザのキャッシュとは限らんよ。
ブラウザに到達するまでに色んな所でキャッシュする装置が挟まってることは良くある。
ファイヤーウォールとか、キャッシュサーバとか、プロクシとか。
0398nobodyさん
2006/05/28(日) 10:58:28ID:???ずっとログイン状態が続いてるよね。
あれってどうやって実現してるんだろう？（＆セキュリティ的に大丈夫か？？）
0399nobodyさん
2006/05/28(日) 11:25:26ID:???一時期流出してたしどこか有るでしょ。
0400nobodyさん
2006/05/28(日) 14:17:29ID:???たしかにネットカフェとかでmixiにログインして
そのままログアウトし忘れてそのまま帰っちゃうヤツとか多そうで危ないな。
0401nobodyさん
2006/05/28(日) 22:38:46ID:???ネカフェでミクシなんてあり得ないでしょ。
個人情報漏れまくりだ。
0402nobodyさん
2006/05/28(日) 23:06:01ID:???だってPCに詳しくない女性とかライトユーザが超多いから。
0403nobodyさん
2006/05/28(日) 23:26:26ID:???「次回から自動的にログイン」のチェックを入れてログインしないと、そんな事にはならないでしょ。
当たり前の実装が普通にしてあったぞ。
0404nobodyさん
2006/05/29(月) 00:00:21ID:???ハァ？？
「次回から自動的にログイン」にチェックを入れなくても
ログインが継続される仕様になってるから>>398のような疑問が出るわけだが。
今、俺が実際に実験してみたところ、「次回から自動的にログイン」をチェックせずに
ログインした状態でパソコンを再起動してもログインが継続されていた。
すなわちネカフェなどでの使用は超危険。
0405403
2006/05/29(月) 00:11:26ID:???http://mixi.jp/help.pl#10dこうも書いてあるし、バグレポ送ったらｲｲﾝｼﾞｬﾏｲｶ。
正直、そんなバグあったら界隈で大騒ぎされているとおもうが。。
0406nobodyさん
2006/05/29(月) 00:34:08ID:???チェック無し
→有効期限無し＝セッション限り
チェック有り
→有効期限2011年5月28日
再起動後もログインが継続されるとすると、ブラウザ側に問題があるが、
そういうブラウザがあるなら気をつけた方が良いな。
0407406
2006/05/29(月) 00:35:03ID:???0408nobodyさん
2006/05/29(月) 00:40:42ID:???現在進行形で祭り中
資料４（最新版） http://myon.blog.shinobi.jp/Entry/4/
0409nobodyさん
2006/05/29(月) 08:11:43ID:???便利だからって理由で「次回から自動的にログイン」にチェック入れてるでしょ。例え不特定多数が使うPCでも。
0410nobodyさん
2006/05/29(月) 10:09:07ID:???0411nobodyさん
2006/05/29(月) 19:46:17ID:???俺もIE6なんだが、、、バグだろうか？？
「自動ログイン」にチェック入れなくても、
ブラウザ閉じようがPC再起動しようが、ログイン状態が継続されてるよorz
みんなそうだと思ってたら、俺だけなのか・・・
0413nobodyさん
2006/05/29(月) 21:43:17ID:???「自動ログイン」のチェック無しでログインすると
「BF_SETTING」って項目とデータ７行。
「自動ログインあり」だと、「BF_SETTING」に加えて、
「BF_SESSION」と「BF_STAMP」ってのが追加されるみたいだね。
0417nobodyさん
2006/05/30(火) 08:23:17ID:???ログアウトしてるのに、クッキー消したら認証突破できるんじゃね？
0418nobodyさん
2006/05/30(火) 09:43:25ID:???ん？ 何を見当違いのこと言ってんだ？
「ログアウト判定のクッキー喰わせてる」って、何を根拠に言ってんだか・・・
0421nobodyさん
2006/05/30(火) 20:39:32ID:???0422nobodyさん
2006/05/30(火) 22:36:56ID:???0423nobodyさん
2006/05/31(水) 12:02:25ID:???0424nobodyさん
2006/05/31(水) 12:57:55ID:???0425nobodyさん
2006/05/31(水) 14:17:24ID:???0426nobodyさん
2006/05/31(水) 15:24:58ID:???0427nobodyさん
2006/05/31(水) 16:23:12ID:???0428nobodyさん
2006/05/31(水) 22:07:23ID:???（ ・ω・）
○=｛=｝〇,
|:::::::::＼, ', ´
.ｗｗし ｗ`（.＠）ｗｗｗｗ
0429nobodyさん
2006/07/01(土) 04:01:59ID:???なおかつ、結果と、ソート状態、何ページ目は、他のページを開いても戻って来た時保持したい。
いちいちGETやPOSTからsqlクエリを毎度生成するのはめんどくさ過ぎるから、
検索条件が投げられた時点でsql文をつくって、まるごとセッションにぶち込む。URLにGETに含めるのは現在何ページ目、ソート対象、ソート方向、表示件数だけにしてしおうかと思ってるけど、こういうのはありなのかな？
0430nobodyさん
2006/07/01(土) 08:44:44ID:???2枚ウインドウを開いて違う検索しようとしたら、一方の検索条件が両方に適用されて
まともに使えないサイトがあった。
ウインドウ毎に区別されるようにしてね
0431nobodyさん
2006/07/01(土) 10:15:18ID:???暫く前の@type(転職サイト)がそう。最悪の使い心地だった。
今は他社同種のと同程度には改良されてるけど。
0432nobodyさん
2006/07/01(土) 16:27:38ID:???なるほど。そういう弊害もあるのか。
いい事聞いた。ありがと。
やはり自分で想定できることってかぎられてるんだなと。
だったら新たに窓を開いたら窓ごとに別のセッションネームをつけてsql文を格納すればよさそうですね。
表示部分の関数がsql文をわたす設計で、結果からのリンクはすべてget渡しなんで、関数内でsql文を生成するとおそろしく面倒なことになりそうだ。
0433432
2006/07/04(火) 11:39:42ID:???でもこれが完成したらすげー楽になるかも。
0434nobodyさん
2006/07/04(火) 19:13:45ID:???0435432
2006/07/04(火) 22:41:35ID:???全ての入力を統合するのは、やっぱり無理っぽいかも。もう限界に近づいて来たというのに、ひどい状態になってしまったorz
コメントアウトだらけで自分でもわけわからん、
0436nobodyさん
2006/07/05(水) 03:10:54ID:???0437nobodyさん
2006/07/05(水) 08:45:55ID:???0438nobodyさん
2006/07/11(火) 09:18:37ID:3lRF8+baアイドル状態が続くとセッションが切れてしまうのを
回避する方法を考えています。
・ サーバでのセッション保持期間を長くする
・ セッションでなくクッキーなどによる管理に変更する
これ以外になにかいい方法があったら教えてください
0439nobodyさん
2006/07/11(火) 09:21:58ID:???普通に考えたらクッキーだよな。
面白い方法だと、例えば幅無しのフレーム作って、そっちのフレームの中を<META>タグで
何秒か置きに更新させて、その中でセッションを更新させてやるとか。
↑まぁこんな事やる意味が分からないけどね(w
0440438
2006/07/11(火) 13:01:04ID:???フレームはちょっと考えてました。
あとはFlashとかで定期的に通信するとか。
でも最後の手段と考えてます。
クッキーの場合は、パスワードも暗号化したクッキーとして
クライアントに返して
毎回そのクッキーで認証するって感じでしょうか？
0442nobodyさん
2006/07/11(火) 14:59:31ID:???クッキーやワンタイムパスワードは総当たり攻撃で突破される。
そもそもHTTPなんてステートレスなプロトコルでセッションが切れるのは仕様。
SOAPとかCORBAとか他のプロトコル使ったら？
0443nobodyさん
2006/07/12(水) 02:04:51ID:???＞アイドル状態が続くとセッションが切れてしまう
session.cookie_lifetimeが「0」なら、
ブラウザを閉じない限りセッションも切れないだろ。
しかもそれってデフォルト設定だし。
0445nobodyさん
2006/07/12(水) 13:24:04ID:???削除されないよ。
実際自分のとこで動かしてるスクリプトは、
一度ログインしたらブラウザ閉じるまで何日でもログイン状態（＝セッション）続いてるし。
0446nobodyさん
2006/07/12(水) 13:41:31ID:???何日もログインできるってメモリリークしまくりに気づいてないだけじゃ？
0447nobodyさん
2006/07/12(水) 15:45:38ID:???お前が>>442で書いてることは間違い。
セッションはファイル（またはDB）で管理されるものであり、
メモリとは直接関係ない。したがってメモリリークなど起きない。
悔しかったら具体的にどういう根拠でメモリリークが発生するか書いてみたまえｗ
0449nobodyさん
2006/07/13(木) 09:31:31ID:???セッション管理はセッションIDをベースファイルネームにしたファイルベースで行われてて、
セッションIDに対応したファイルがあるかないかだけの話だと思うのだけど、
そこに一体どういう原理でメモリリークが発生するの？？？？
0450nobodyさん
2006/07/13(木) 13:03:32ID:???ガーベッジコレクションの動作についてよく勉強したまえ。
gcは、「ガーベッジ」となっていないものまでは回収しない。
0452あい
2006/07/13(木) 15:17:21ID:se0YFGaK0453nobodyさん
2006/07/13(木) 19:25:58ID:???ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて、解放されないメモリが増えるよ。
事実上メモりリークしてメモリの再活用や再割当が出来なくなる。回収しないのではなくて回収できないメモリが増えていくのがメモリリーク。
0454nobodyさん
2006/07/13(木) 20:38:13ID:???メモリを使用したときでも、きちんと解放がセッション保持のプロセスに含まれてるしメモリリークするとは考えられないが。
0455nobodyさん
2006/07/13(木) 22:45:45ID:???＞ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて
↑こいつキチガイだなｗｗｗ
なんでセッションファイルの数が多いとメモリ使用量が増えるんだよｗ
そしたらセッション以外にもスクリプト自身とか、さまざまファイルが
多ければ多いほどメモリリークが発生する…って理屈になるなｗｗ
0456nobodyさん
2006/07/14(金) 10:42:22ID:???0457nobodyさん
2006/07/14(金) 11:06:20ID:???だから食わねぇっつーの。
そんなに自説を主張したかったらソース出せソースを。
誰がどこでそんな珍説を広めてんだ？
0458nobodyさん
2006/07/14(金) 11:42:37ID:???で、PHPの自動メモリ解放機能とかを知らずに、
最近覚えた「メモリリーク」という言葉を連呼したくてたまらない厨房なのでは？？
まあ、何にせよセッション・ファイルとメモリリークとは関係ない話なんだけどね。
0459nobodyさん
2006/07/14(金) 16:28:29ID:???１０万セッションのサイトでは、１０万セッション分のファイルハンドルが必要なんだよ。
十分メモり喰うし、長時間セッション使ってるとメモリリークも起きる。
0460nobodyさん
2006/07/14(金) 18:25:44ID:???10万セッションも必要なサイトの管理者はこんなスレ来ねぇよバカ。
っていうか10万セッションもあったらファイルハンドラじゃ無理があるからＤＢ使うし、
そもそもサーバ１台じゃなくて複数台に分散するんだよクズ。
0461nobodyさん
2006/07/14(金) 23:07:11ID:???0462nobodyさん
2006/07/14(金) 23:48:16ID:???しかも負荷分散しないでやってたら（やれるとしたら）、
そもそもメモリリーク以前にもっと別の問題が起きると
思うけどなｗｗ
0465nobodyさん
2006/07/16(日) 09:00:01ID:???恥さらしもその辺にしとけよ(w
0466nobodyさん
2006/07/16(日) 10:37:13ID:???0468nobodyさん
2006/07/17(月) 04:55:48ID:???その前にメモリ喰いまくりで太ったアパッチごとkillされる。
■ このスレッドは過去ログ倉庫に格納されています