822コメント255KB

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

■ このスレッドは過去ログ倉庫に格納されています

0001nobodyさん

03/09/24 19:31ID:SnRvXmpI

ブラウザを閉じたらセッションの効果がなくなるのって、
ブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん

0449nobodyさん

2006/07/13(木) 09:31:31ID:???

PHPのデフォのセッションの場合、
セッション管理はセッションIDをベースファイルネームにしたファイルベースで行われてて、
セッションIDに対応したファイルがあるかないかだけの話だと思うのだけど、
そこに一体どういう原理でメモリリークが発生するの？？？？

0450nobodyさん

2006/07/13(木) 13:03:32ID:???

>>448
ガーベッジコレクションの動作についてよく勉強したまえ。
gcは、「ガーベッジ」となっていないものまでは回収しない。

0451nobodyさん

2006/07/13(木) 13:36:25ID:???

>>442
＞セッション保持はメモり喰うし、メモリリークが発生しやすい

アタマ大丈夫？？

0452あい

2006/07/13(木) 15:17:21ID:se0YFGaK

sessionについて教えてください!

0453nobodyさん

2006/07/13(木) 19:25:58ID:???

総当たり攻撃で突破できる弱いユーザ管理です。

ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて、解放されないメモリが増えるよ。
事実上メモりリークしてメモリの再活用や再割当が出来なくなる。回収しないのではなくて回収できないメモリが増えていくのがメモリリーク。

0454nobodyさん

2006/07/13(木) 20:38:13ID:???

セッションの保持にメモリが使用されるのはコンパイルオプション付けたときだけだろ。
メモリを使用したときでも、きちんと解放がセッション保持のプロセスに含まれてるしメモリリークするとは考えられないが。

0455nobodyさん

2006/07/13(木) 22:45:45ID:???

>>453
＞ファイルでもDBでもセッションが多数に成ればその分だけメモリの使用量が増えて

↑こいつキチガイだなｗｗｗ

なんでセッションファイルの数が多いとメモリ使用量が増えるんだよｗ
そしたらセッション以外にもスクリプト自身とか、さまざまファイルが
多ければ多いほどメモリリークが発生する…って理屈になるなｗｗ

0456nobodyさん

2006/07/14(金) 10:42:22ID:???

ファイルハンドルでメモリ喰うから。プログラムやったこと無いの？

0457nobodyさん

2006/07/14(金) 11:06:20ID:???

>>456
だから食わねぇっつーの。
そんなに自説を主張したかったらソース出せソースを。
誰がどこでそんな珍説を広めてんだ？

0458nobodyさん

2006/07/14(金) 11:42:37ID:???

>>456はおそらく、Ｃ言語を中途半端にかじったヤツである悪寒。

で、PHPの自動メモリ解放機能とかを知らずに、
最近覚えた「メモリリーク」という言葉を連呼したくてたまらない厨房なのでは？？

まあ、何にせよセッション・ファイルとメモリリークとは関係ない話なんだけどね。

0459nobodyさん

2006/07/14(金) 16:28:29ID:???

馬鹿だなあ。
１０万セッションのサイトでは、１０万セッション分のファイルハンドルが必要なんだよ。
十分メモり喰うし、長時間セッション使ってるとメモリリークも起きる。

0460nobodyさん

2006/07/14(金) 18:25:44ID:???

>>459
10万セッションも必要なサイトの管理者はこんなスレ来ねぇよバカ。

っていうか10万セッションもあったらファイルハンドラじゃ無理があるからＤＢ使うし、
そもそもサーバ１台じゃなくて複数台に分散するんだよクズ。

0461nobodyさん

2006/07/14(金) 23:07:11ID:???

愛のメモリリーク

0462nobodyさん

2006/07/14(金) 23:48:16ID:???

っていうか10万セッションをファイル使って、
しかも負荷分散しないでやってたら（やれるとしたら）、
そもそもメモリリーク以前にもっと別の問題が起きると
思うけどなｗｗ

0463nobodyさん

2006/07/15(土) 00:26:38ID:???

>>459
もう少し勉強したら自分がキチガイなこと言ってるって分かるよ。

0464nobodyさん

2006/07/15(土) 01:04:45ID:???

>>459は、まれにみるバ（以下略

0465nobodyさん

2006/07/16(日) 09:00:01ID:???

>>459はセッション処理の為に開かれたファイルは、そのまま開かれているものとして語っているみたいだな。
恥さらしもその辺にしとけよ(w

0466nobodyさん

2006/07/16(日) 10:37:13ID:???

つまりセッションは大規模サイトでは無理ってことですね。

0467nobodyさん

2006/07/16(日) 13:34:14ID:???

>>466
だから何を見当違いのことを言ってんだ、おまいは。
もしやおまいは>>459＝>>456か？？

0468nobodyさん

2006/07/17(月) 04:55:48ID:???

phpで１０万セッション自体があり得ない。
その前にメモリ喰いまくりで太ったアパッチごとkillされる。

0469nobodyさん

2006/07/17(月) 09:19:18ID:???

〃∩ ∧　∧
⊂⌒（　・ω・）　　はいはいわろすわろす
　｀ヽ_っ⌒/⌒ｃ
　　　　⌒ ⌒

0470nobodyさん

2006/07/18(火) 01:12:16ID:???

大丈夫。リナクスの場合は１０万セッションも接続北来た瞬間再起動するから(w
2003鯖を使ってる漏れは勝ち組。

0471nobodyさん

2006/07/18(火) 10:40:48ID:???

>>465がトドメという感じだが、流石にもう食い下がってはこないか？？

0472nobodyさん

2006/07/18(火) 13:45:02ID:???

しっかし、「セッションでメモリリーク」なんて珍説、はじめて聞いたよｗｗ

0473nobodyさん

2006/07/18(火) 14:14:20ID:???

メモリリークしないって思い込みって、バグは無いって思い込みで出荷しちゃったシンドラエレベータの殺人プログラマ並みに馬鹿だな。
人氏んでるんやで。プログラムぐらいまともに組め。

0474nobodyさん

2006/07/18(火) 15:06:36ID:???

詭弁の見本市みたいになってきたな。

0475nobodyさん

2006/07/18(火) 17:17:25ID:???

>>473
だからメモリリークが発生するというのなら、
具体的な根拠や発生機序を示せよ。

0476nobodyさん

2006/07/19(水) 03:06:06ID:???

港区のエレベータで死亡事故。
上昇直前に開ボタンを押すとメモリリークが発生して死亡事故が起きる。

0477nobodyさん

2006/07/19(水) 03:15:59ID:???

メモリリークするって思い込みって、バグは無いって思い込みで出荷しちゃったシンドラエレベータの殺人プログラマ並みに馬鹿だな。
人氏んでるんやで。プログラムぐらいまともに組め。

0478nobodyさん

2006/07/19(水) 03:18:08ID:???

セッションといえばWeb製作板の携帯スレで暴れてた馬鹿が居たが、同一人物っぽい香りがするな(w

0479nobodyさん

2006/07/19(水) 09:14:38ID:???

> メモリリークが発生して死亡事故が起きる。
おめでたい思考回路ですね。

0480nobodyさん

2006/07/19(水) 09:24:01ID:???

他人に何を言われても引き下がらない
とても漢らしい生き方だと思いました

0481nobodyさん

2006/07/19(水) 11:23:40ID:???

往生際が悪い　の間違いだろ(w

0482nobodyさん

2006/07/19(水) 14:01:34ID:???

メモリリークは発生するってことでおｋ？

0483nobodyさん

2006/07/19(水) 15:31:59ID:???

テポドン２の発射もメモリリークが原因！　とか言い出しかねないなｗｗｗ

0484nobodyさん

2006/07/19(水) 16:58:02ID:???

ハワイまで到達できなかったのはメモリリークでしょ。

0485nobodyさん

2006/07/20(木) 01:22:24ID:???

セッションによるメモリリークの存在を強硬に主張しているが、
いまだに具体例や証拠が一切出されていないのが笑えるｗ

0486nobodyさん

2006/07/20(木) 10:56:20ID:???

メモリリークの存在を必死に否定しているが、１０万セッション達成の具体例や証拠が一切出されていないのが笑える。

0487nobodyさん

2006/07/20(木) 12:56:36ID:???

今なら言える。

必死だな(w

0488nobodyさん

2006/07/21(金) 06:32:39ID:???

>>486＝バカ

ヒント；>>460,>>462,>>468

0489nobodyさん

2006/07/21(金) 23:44:57ID:???

メモリリークの意味を知らないか、PHPがステートレスだと言うこと自体知らないんだろ。

0490nobodyさん

2006/07/23(日) 01:17:39ID:???

メモリリーク厨のオモシロ回答まだぁ～～？？ｗｗ

0491nobodyさん

2006/07/26(水) 12:00:14ID:???

>>444-450
これってどういうこと？
ブラウザが閉じられるまでgcが発生しないようになんて
できないよね？
そんな方法があるなら知りたい。

gc_maxlifetimeを1年ぐらいに設定するとかはなしでｗ

0492nobodyさん

2006/07/27(木) 09:05:35ID:???

>>491
ない
445が間違えてるだけ

0493nobodyさん

2006/07/28(金) 07:54:27ID:???

>>491-492
んなこたぁないだろう。
そしたら「ブラウザ閉じない限りはずっとログインし続けたまま」の
システムを作ることが不可能になるじゃんか。

0494nobodyさん

2006/07/28(金) 08:04:14ID:???

つーか、session.gc_maxlifetimeって、
一体どのタイミングからカウントされた秒数なの？

最初のアクセスか、それとも最後のアクセスか・・・

0495nobodyさん

2006/07/28(金) 08:42:49ID:???

>>493
不可能だし

>>494
まず試せ

0496nobodyさん

2006/07/28(金) 09:24:42ID:???

>>494-495
まずググれ。
が，正解かと。

0497nobodyさん

2006/07/28(金) 14:19:59ID:???

>>495
不可能じゃないよ。
だってmixiとか、ブラウザ閉じなければ何日でもずっと
ログイン状態が継続してるし。

0498nobodyさん

2006/07/28(金) 16:48:36ID:???

>>497
それ、セッションじゃなくて、クッキーにユーザー名とか保存してるだけじゃ無いの？
セッション何日も維持するなんて、セキュリティ上あり得んよ。

クッキーに何を保存してるか、見てみれば？

0499nobodyさん

2006/07/28(金) 18:55:06ID:???

mixiはブラウザ閉じても次アクセスすればログイン状態では？
ちなみにクッキーは3個。すべてセッションオンリーはNO、有効期限は5年。

クッキーにユーザー名とか保存はしてない。直接の値が書き込まれているのは表示設定のみ。
ていうかそっちの方がセキュリティ上問題あるだろう

0500nobodyさん

2006/07/28(金) 20:37:40ID:???

>>498
mixiのクッキーにはユーザー名（メアド）は書いてないよ。

>>499
＞セッションオンリーはNO
↑これどういう意味？？

＞mixiはブラウザ閉じても次アクセスすればログイン状態では？
「次回から自動ログインする」にチェックを入れてログインしたなら、ね。

0501nobodyさん

2006/07/28(金) 21:47:39ID:???

>>500
＞セッションオンリー
ブラウザを終了したらクッキーを破棄するかどうか（これがオンだと有効期限は設定されない）

「次回から自動ログインする」にチェックしたらセッションオンリー=オフで有効期限5年のクッキー
チェックしなかったらセッションオンリー=オンのクッキー
という使い分けみたいですね。

0502nobodyさん

2006/07/28(金) 22:13:32ID:???

>>501
あれっ、mixiのクッキー内にそんなデータあった？？
俺見てみたけど、見当たらないぞ・・・

っていうか「BF_STAMP」って何を指してるんだろう？　BFが何の略なのかも気になる。

0503nobodyさん

2006/07/28(金) 23:41:45ID:???

>>501
言いたいことは分からないでもないが
セッションオンリー
って言葉はどうなの？

>>502
独自のセッションを実装してるみたいだね
ワンタイムパスワードみたいなのを3つくらい返してる
mixiって同じIDで別の端末からも利用できるの？
できるんならサーバ側の情報管理はたいへんそうだな

0504nobodyさん

2006/07/29(土) 02:55:05ID:???

>>503
たしかにワンタイムパスワードみたいなのがあるね。
でも何回かログインとログアウトを繰り返してみたところ、
そのワンタイムパスワードみたいなのは変化しなかった。
ってことは「ワンタイム」じゃない！？

0505nobodyさん

2006/07/29(土) 09:11:18ID:???

>>504
ってことはmd5とかで変換しただけのものを
クッキーに保存して毎回アクセスするたびに認証してるだけだね
セッションじゃないじゃん

一番確実な方法だと思うが
セキュリティ的にはhttpsでもないしだめだと思う

0506nobodyさん

2006/07/29(土) 11:57:07ID:???

気になったからみてみた＞mixi

BF_SESSION
が 999_jidjaijdiojaidjhifjaj1399
みたいになってて先頭の数字が会員IDで後ろは
会員に対するランダムな文字列
（ってことで会員IDもかかれてるよ）

BF_STAMP
がパスワードになにかしたもの。
（パスワードを変更すると変化する）

BF_LOCAL_SESSION
が一時的なセッション管理用っぽい。

認証はCOOKIE（BF_SESSIONとSTAMP）で管理して
一時的なセッション情報（すぐに消えてもいいもの）を
BF_LOCAL_SESSIONのほうでやってると思われ。

ちなみに BF_ がなんの略かは分からない。

0507nobodyさん

2006/07/29(土) 12:17:15ID:???

BFはmixiのコアライブラリBoofyのことやろね。
以前フロントエンドのソースコード流出で話題になってた。

0508nobodyさん

2006/07/29(土) 13:13:55ID:???

mixiは招待無しで参加できないの？

0509nobodyさん

2006/07/29(土) 13:30:05ID:???

無理

0510nobodyさん

2006/07/29(土) 13:37:05ID:???

そこをなんとか

0511nobodyさん

2006/07/29(土) 15:33:58ID:???

>>506が神に一歩近づきました。

mixiはDBもロードバランスしてたりするから、
セッション管理とかもやたら複雑なんだろうなぁ。。。

もっと小規模のSNSだったなら、そこまで複雑なCOOKIEにならないで済むのかな？
たとえばOpenPNEとか。使ったことないけど。

0512nobodyさん

2006/07/29(土) 22:34:06ID:???

>>511
> >>506が神に一歩近づきました。
> mixiはDBもロードバランスしてたりするから、
> セッション管理とかもやたら複雑なんだろうなぁ。。。
レイヤ7スイッチなら関係なし

0513nobodyさん

2006/07/29(土) 23:50:54ID:???

通常完全ランダムなハッシュを一つクッキーに入れるのが一番良いんだと思うんだけど、
なんかmixiは色々と入れてるんだね。しかも会員情報と関係する物を。

0514nobodyさん

2006/07/30(日) 00:07:51ID:???

>>513
完全ランダムなハッシュ？
どうやって認証するの？
セッション使うってこと？

0515513

2006/07/30(日) 00:19:58ID:???

ログイン時にランダムなハッシュをクッキーとして渡して、鯖側でユーザと結びつけて管理。
いや、別に変わった事言ったわけではないっす。セキュリティを確保する為の問題はそこからだよね。。

0516nobodyさん

2006/07/30(日) 10:32:58ID:???

っていうか普通そうすると思うが

0517nobodyさん

2006/07/30(日) 12:19:56ID:???

その普通が出来ていないサイトがなんと多いことか・・・
man in the middleを考えるならSecure発行も必須だな。

0518nobodyさん

2006/07/30(日) 14:03:10ID:???

>>515
> ログイン時にランダムなハッシュをクッキーとして渡して、鯖側でユーザと結びつけて管理。

sessionと何が違うんだ？

0519nobodyさん

2006/07/30(日) 14:28:40ID:???

セッションを語るスレなのにPHPに標準実装されてるセッションをただ"セッション"というのは紛らわｼｽ
ブラウザをIEの同義語で使うのと同レベル

0520nobodyさん

2006/07/30(日) 16:57:26ID:???

>>518
sessionid 以外にハッシュを渡して
認証済みチェックをやるってことだろ

>>519
？？？

0521nobodyさん

2006/07/30(日) 17:04:19ID:???

セッションを実装するには、何もPHPで標準で用意されてるセッションを使わなくてもいいよ
って事が言いたいのでは？違うか？？

0522nobodyさん

2006/07/31(月) 03:14:10ID:???

>>520
PHPのセッション関数によって発行されたセッションIDをクッキーに渡すんじゃダメなの？
>>518も書いてるが、セッションIDとは別にわざわざハッシュ値を用意する意味がよく分からない。

0523nobodyさん

2006/07/31(月) 04:58:39ID:???

CookieをSecureにすると負荷で死ぬから、うちでは自前でセッションハイジャック対策やってるんだが、
そうなると確かにsessionは使えないな。常にSSL使える環境なら標準のでいいんじゃね？

0524nobodyさん

2006/07/31(月) 15:31:17ID:???

>>523
＞自前でセッションハイジャック対策やってるんだが、
＞そうなると確かにsessionは使えない

どうして？？

0525523

2006/07/31(月) 23:55:35ID:???

対策としてログイン時のホストとUserAgentをセッションと結びつけてる。
これをsessionでやろうとすると結果的にハッシュが二重に保存される上に処理にロスが出る。

0526nobodyさん

2006/08/01(火) 04:10:24ID:???

>>525
言ってる意味がわからん。
なんか無駄に難しく考えてないか？

0527nobodyさん

2006/08/01(火) 04:31:43ID:???

https使わない馬鹿なんていないから大丈夫。

0528nobodyさん

2006/08/01(火) 05:39:58ID:???

そろそろセッションはPHPが普及する前からあるときがついてくだしあ。

0529nobodyさん

2006/08/01(火) 07:18:30ID:???

>>525
それを実装したいなら、セッション変数にホストとUA入れればいいじゃん。
ただし、既出のように、それだけではセッションハイジャックを完全には防げないし、
ホスト(IPアドレス)がHTTP接続ごとに変わる環境のやつが利用できなくなる罠。

0530525

2006/08/01(火) 08:56:31ID:???

>>529
ごめん。書き忘れてたんだけど、
複数のアクセスポイントからアクセスする人もいるから、
一つのユーザに複数のセッションを割り当てて管理してます。
その過程でIDと複数のセッションを関連づけてるんだけど、
sessionだとIDからセッションの逆引きが出来ないので。。
ちなみに、ホストが変わるのは適度にマッチングして対応しています。

ところでNonSSLでセッションハイジャックを完全に防ぐ方法ってあるかな？
無理だよね。。まぁ、SSL使えって話しなんだろうけど。

0531nobodyさん

2006/08/01(火) 09:10:48ID:???

>>530
SSLでも完全には防げないし

0532525

2006/08/01(火) 09:18:07ID:???

物理的アクセスとかウィルスはやめてください＞＜
そういや、ny系のウィルスでCookieやらをzipにして流すのがありましたね。

0533nobodyさん

2006/08/01(火) 10:44:03ID:???

>>530
っていうかSSLは通信内容を暗号化するだけで、
セッションハイジャックを防ぐ手段とは関係ないわけだが。

0534525

2006/08/01(火) 10:58:20ID:???

いやー、そりゃねーだろー。
不安になって確認しちまったじゃんか。ぐぐればざくざく出てきますぜ。

0535nobodyさん

2006/08/01(火) 11:28:28ID:???

じゃそういうことで。

0536nobodyさん

2006/08/01(火) 11:40:56ID:???

誰か533を俺にも分かるように解説してくれ

0537nobodyさん

2006/08/01(火) 12:04:03ID:???

>>536
ぐぐればざくざく出てきますぜ

0538nobodyさん

2006/08/01(火) 17:01:25ID:???

そんなセッションな、

0539nobodyさん

2006/08/02(水) 03:45:11ID:???

というか、ログイン認証時以外にも常にHTTPSで通信するなんて
実用的には無理があるよな。

mixiみたいに、認証時以外はHTTPにするしかないだろ。
負荷やレスポンスなどを考えると。

0540nobodyさん

2006/08/02(水) 04:30:58ID:???

mixiはセッション管理的にアレだけどな。
重要な情報をやりとりするとき以外はhttpでいいんじゃね。
YahooもBiddersも楽天だってAmazonだってそうしてるし。
鯖側よりクライアントに負荷の比重を置くセキュアプロトコルが欲しいところだな。

0541nobodyさん

2006/08/02(水) 10:40:13ID:???

https通信時にどういうやり取りが行われてるか見ればわかると思うが、
負荷を考えるのであれば全てをhttpsでやろうとするのはナンセンスだよな。
1日10アクセスぐらいのサイトなら好きにすりゃいいけど(w

0542nobodyさん

2006/08/02(水) 10:59:10ID:???

会員専用以外のとこで
すべてをhttpsでやってるとこなんてあるの？

0543nobodyさん

2006/08/02(水) 14:11:39ID:???

ないだろｗ

0544nobodyさん

2006/08/03(木) 03:05:25ID:???

っていうかさぁ、みんな「セキュリティ、セキュリティ・・・」って念仏のように唱えてるけど、
実際にSSLを使わずに重要情報をスニファされた事件って、実例あるの？
そんなもん、いまだに聞いたことないんだが。

0545nobodyさん

2006/08/03(木) 05:30:21ID:???

泥棒に入られたことなくても、家に鍵かけるだろ？

0546nobodyさん

2006/08/03(木) 09:38:22ID:???

>>545
実際には存在しない「架空の泥棒」を生み出して大騒ぎし、
人々の恐怖心を煽って大儲けしているヤツらがいることに少しは気付こう。
だからキミらはいつまで経っても搾取され続けるんだよ。バカだから。

そんなキミらは映画『ボウリング・フォー・コロンバイン』でも見ると良い。

0547nobodyさん

2006/08/03(木) 10:26:30ID:???

まぁ、プロと素人の意識の差だね。
素人の趣味でやるなら好きにすりゃいい。

0548nobodyさん

2006/08/03(木) 10:39:54ID:???

>>547
論点のすり替え乙。

意識だのプロだの関係ない。
ただ単に想像の産物で騒いでるお前みたいなバカのことを笑ってるだけだよ。

■ このスレッドは過去ログ倉庫に格納されています