トップページ⇒php
822コメント255KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん03/09/24 19:31ID:SnRvXmpI
ブラウザを閉じたらセッションの効果がなくなるのって、
ブラウザを閉じることでクッキーを消しているからなのですね。。
知らなかったよーーーーうわーーーん
0552nobodyさん2006/08/04(金) 00:27:39ID:???
>>544
会社でなら
0553nobodyさん2006/08/04(金) 02:33:39ID:???
たしかにSQLインジェクションとかXSSとかが原因の事件はよくニュースになるけど、
SSLを使用しないせいでパケットスニファされた事件なんて記憶にないな。

誰か実例知ってる?
0554nobodyさん2006/08/04(金) 02:42:38ID:???
過疎ってるSSLのスレがあるからそっちでやれ

SSLの使い方
http://pc8.2ch.net/test/read.cgi/php/1016169881/
0555nobodyさん2006/08/04(金) 03:24:34ID:???
別に去る者追わずの個人サイトならそれでいいんじゃね。
ユーザの事考えなくても良い素人ならね。
0556nobodyさん2006/08/04(金) 09:33:12ID:???
>>555
何回もクドクドとウゼェなぁ。「素人、素人」って、お前は何様なんだボケ。
つーか歯車リーマンが何を偉そうに語ってんだバカが。

悔しかったら早くスニファが原因での情報漏洩事件を挙げてみろカス。
0557nobodyさん2006/08/04(金) 09:45:01ID:???
同一ネットワークでARPが届く範囲ならフニファできるけど
それ以外だと無理だとおもわれ。ルータでARPがクッションされるから。
0558nobodyさん2006/08/04(金) 13:38:11ID:???
>>556
獲得できるユーザが少なくなったり評判が悪くなるって言ってるんだよ。白書読め。
キミはユーザにそう説明してれば良いんじゃない?
0559nobodyさん2006/08/04(金) 18:57:12ID:???
>>558
言い訳は要らないから、早く実例出せよ。

SQLインジェクションやXSSでの被害実例は豊富にある。
だからその対策を講じるのは合理的な理由がある。

しかしSSLを使用しなかったことによるスニファでの被害実例は、少なくとも俺は知らない。
まさかお前、実際にはありもしない不安を煽って、客から高い金取ってるんじゃないだろうな?
そういうのを詐欺とかボッタクリと呼ぶんだぜ。
0560nobodyさん2006/08/04(金) 19:02:25ID:???
UZEEEE
勝手にベリサインにでも電凸でもしてSSLサイトでも作ってろ
いつまでスレ違いネタ続ける気だ死ね
0561nobodyさん2006/08/04(金) 19:04:12ID:???
まちげぇた
SSLサイト→SSL叩きサイト
掲示板のルールすら守れないやつが正義漢振るな
ゴミが
0562nobodyさん2006/08/04(金) 19:42:52ID:???
>>559
まさかここまで言っても分からない馬鹿だとは思わなかった。
被害がある被害がないは関係ないんだよ。ユーザがそれを気にしているかどうか。SSLを使用しているかどうかをチェックするユーザがいる事実、これだけが大事。
XSS、インジェクション、それらの対策がなされているかチェックしてからサイトを使うユーザが何処にいる?
それに対しSSLのチェックは簡単で、大きくメディアにも取り上げられている。また、上にも挙げたとおりいくつかの白書に載っている統計にもユーザがそれらを判断基準にしているとの統計が出ている。
お前みたいなユーザ数を気にする必要のない素人には関係ないがな。ユーザ数獲得を目的とする"プロ"の"SSL使用"の何処が非合理なんだか。

セキュリティよりもお前は自分の馬鹿さ加減を気にした方が良いな。
0563nobodyさん2006/08/04(金) 19:59:46ID:???
これ以上エサを与えんなよ
空気読まない質問に答えてやってもいい相手は小さい子供だけだ
0564nobodyさん2006/08/04(金) 20:56:55ID:???
だから素人は好きにやっとけって事でFAで終了

いつまでやってんだか。。。
0565nobodyさん2006/08/04(金) 23:02:49ID:???
セッションで呼び出す毎にハッシュ変更する機能付けるのってどうやってやるんだっけ?
何処かで見たような気がするんだけど思い出せん
0566nobodyさん2006/08/04(金) 23:14:01ID:???
>>565
session_start();
session_regenerate_id();

こゆこと?
0567nobodyさん2006/08/05(土) 03:45:03ID:???
>>562
いやぁ、スゴい論点ずらしの逃げだね。見事な負け犬っぷりだwww
お前みたいな馬鹿システム屋がいるせいで、ますますド素人の客やユーザーたちは
「SSLさえあれば安全!」みたいな間違った認識を増大させ、
もっと重要かつ事件が頻発している穴をふさぐための費用を出そうとしない。


それからユーザ数獲得云々とか、お前の論理なんてどうでもいいわけ。そんなの誰も聞いてないだろ。
そうじゃなくて「SSLが無い場合の危険度=過去に起きた被害実例」を挙げてみろよ、って言ってんの。
もしユーザからそれを質問されたらどう答えんの? あ?

お前の論理でいくと、「ユーザ数獲得を目的とするプロ」なら、上記の質問には答えて然るべきだよなぁwww
0568nobodyさん2006/08/05(土) 04:17:59ID:???
ユーザは使用者、君が言ってるのはクライアント。ユーザはわざわざSSLが無いサイトを選んだりしません。
在日の君にはまず日本語を覚えて貰わないと話しにならないなぁ。
しかも、>>555に最初にレスしてきたのは君でしょ。それがルートレスになってるんだからそのレスに基づいて話すのは当たり前。論点をずらさないで欲しいね。

まぁ、君の質問にも答えてあげると、情報の盗聴というごくごく受動的な行為は被害を受けたと認識する事は出来ないってこと。
被害実例?気づいてないんだから少ないのは当たり前。普段と何ら変わりないのにどうやって気づく?個人情報漏洩した企業の"情報の悪用は確認できない。"という言い訳と同じ。
その前に君はなぜベリサインなどの企業が成り立っているか考えるべき。受動的攻撃の検知に疎いのは良いとして、こちらは世間一般で分かる常識だ。
"間違った認識をする奴がいるから"ベリサインは成り立つ。そんなはずがないだろう。もう少し謙虚に生きた方が多くのことを学べるよ。
0569nobodyさん2006/08/05(土) 05:07:23ID:???
長文は読む気も書く気もしないので。

ま、クレジットカード番号送るのに、SSLも使ってないサイトを使いますか?って事だ。
で、素人は好きにやっとけって事でFAで終了。他所いってやってくれ。
0570nobodyさん2006/08/05(土) 05:29:11ID:???
きっと考えが営業的なんだと思うよ。
お金を投入して、それに見合う効果があるのかどうかという話。

観測できない被害は、あったとしても気づいていなければ、会計的に被害額を算出不能なので被害に遭ってないのとのと同じ。
また、その観測できない被害を被るのは、多くの場合サイトの運営側でなく利用者の側なので被害を受けるとみなさないとする向きもあるかと思う。
そういう考え方は賛同はできないけれど、「あり」な考えかたの一つだと思う。

利用者から安全でないと思われ、最初から利用を控えられるということによる損失。
情報流出の被害が発覚した場合の信用失墜による損失。
こういったものを軽く見積りすぎているように思います。

もちろん、被害が発覚して問題になったときの対応にかかるコストも含めて、事後対応のほうがコストが安いと思うならそれもありです。通常はかなり高くつくようですけど。
0571nobodyさん2006/08/05(土) 05:40:23ID:???
一言で書けば価値観の違い。
ボッタクリと思うのなら使わなければ良い話。
価値観の押し付けウザ。長文ウザ。


で、素人は好きにやっとけって事でFAで終了。
頼むから他所いってやってくれ。
0572nobodyさん2006/08/05(土) 10:11:11ID:???
セミが鳴き始めたようだな
0573nobodyさん2006/08/05(土) 10:21:38ID:???
ガキは市民プールで遊んでろ。
0574nobodyさん2006/08/05(土) 10:57:40ID:???
>>571
お前が一番ウザいということに早く気付けよチンカスくん。
>>568で自ら長文書いてるし。お前ウザいんだよ。5回くらい氏ねやボッタクリ屋。
0575nobodyさん2006/08/05(土) 10:58:39ID:???
それともう言い訳は聞き飽きたから、
早く「SSL不使用によるクレジットカード番号流出」の実例を挙げろ。

言い訳や、捨てゼリフによる逃げはもう飽きたからいいよ。
0576nobodyさん2006/08/05(土) 13:13:10ID:???
>>574
ん?長文書いてる奴は俺じゃないぞ??
SSL不使用によるクレジットカード番号流出?そんなのシラネーヨw

ま、クレジットカード番号送るのに、SSLも使ってないサイトを使いますか?って事だ。
価値観の押し付けウザ。長文ウザ。
で、素人は好きにやっとけって事でFAで終了。他所いってやってくれ。
0577nobodyさん2006/08/05(土) 13:15:13ID:???
クレジットカード番号送るのに、SSLも使ってないサイト
↑で金を取る方がボッタクリだと思った。

あと>>575の人コテハンにしてくれ。アボンしとくから。
0578nobodyさん2006/08/05(土) 17:48:27ID:???
>>542
>会員専用以外のとこですべてをhttpsでやってるとこなんてあるの?
あった
http://portal.askul.co.jp/
0579nobodyさん2006/08/06(日) 00:13:53ID:???
>>578
準会員制みたいなもんですね
微妙だけど
0580nobodyさん2006/08/06(日) 20:38:27ID:???
>>576
だから逃げるなって、チンカス。
「クレジットカード番号送るのに、SSLも使ってないサイトを使いますか」って、
お前の主張なんか誰も聞いてないんだよ。早くSSLを使わなければ問題が起きるという実例を示せ。

「価値観の押し付けウザ」 ← これをそっくり熨斗でもつけてチンカスに返却しましょう。
0581nobodyさん2006/08/06(日) 21:10:38ID:???
何かのレポートの宿題か?
自分でやれ
0582nobodyさん2006/08/07(月) 06:22:05ID:???
たかだかSSLの設定が出来ない香具師が騒いでいるだけ。
SSLあり/なしの両方で運用できるように書いときゃいいだけなのに。
0583nobodyさん2006/08/07(月) 09:25:34ID:???
>>582
論点のズレた認識乙。

>SSLあり/なしの両方で運用できるように
実際の運用に当たってはそんなの当たり前だろボケカス。
そもそも、話の流れはそういうことを言ってるんじゃないだろうが。
SSL無しの場合の被害実例を早く挙げてみろって言ってんだよ。
いつまで逃げてんだチンカス。
0584nobodyさん2006/08/07(月) 09:36:34ID:???
単位はあきらめろ
0585nobodyさん2006/08/07(月) 09:47:08ID:???
「SSLを使わなければ問題が起きるという実例を示せ」って、
お前の主張なんか誰も聞いてないんだよ。
早く「クレジットカード番号送るのに、SSLも使ってないサイトを使いますか」に回答しろ。
0586nobodyさん2006/08/07(月) 09:48:54ID:???
>>580ってweb製作板の「携帯端末用のWeb制作」で暴れていた馬鹿と同じやつだな。
結局GETが何かすら分かってなかったというオチで逃げ去った馬鹿。
放置推奨。
0587nobodyさん2006/08/07(月) 09:55:59ID:???
>577に一票
0588nobodyさん2006/08/07(月) 10:00:44ID:???
>583
結局こいつは何がいいたいの?w
誰か説明して
0589nobodyさん2006/08/07(月) 17:37:02ID:???
皆さんドコモ向けのセッションってsession.use_trans_sidでやってますか?
0590nobodyさん2006/08/07(月) 18:48:37ID:???
>>589
面倒な時はそうしてる
0591nobodyさん2006/08/08(火) 10:14:27ID:???
>>584-588
悔し紛れのジサクジエン乙。
でもお前ジエンし杉だから、ほどほどにな。

で、早くその逃げの人生を止めろよ。
答えに窮する事実を突きつけられたからって、発狂しちゃいかんよキミwww
0592nobodyさん2006/08/08(火) 12:37:31ID:???
>>591
移動しろ話はそれからだ

セキュリティ初心者質問スレッドpart73
http://pc8.2ch.net/test/read.cgi/sec/1154835858/
0593nobodyさん2006/08/10(木) 08:32:10ID:???
そうして>>592は「答えられない質問」から逃げ通すことに成功した。
その後彼は一生逃げ続けるヘタレな人生を送るのであった。
めでたしめでたし。
0594nobodyさん2006/08/10(木) 12:30:02ID:???
( ゚д゚ )
0595nobodyさん2006/08/10(木) 18:09:09ID:???
質問への返答よりもスレ違いな場所で質問する事のが重要ってことか
死ねばいいのに
0596nobodyさん2006/09/30(土) 23:07:37ID:ev1i2goA
unset($_SESSION)してしまった場合の対処法おしえてくださいっ!
結構探したけどみつかんないです。。。
0597nobodyさん2006/10/01(日) 01:06:19ID:???
>>596
// unset($_SESSION)
でオケ
05985962006/10/01(日) 06:04:12ID:u4OUdACZ
>>597
レスありがとー。

ということは session 機能がいきなり動かなくなったのは
これが原因じゃないのね。

>unset($_SESSION)によって 全ての$_SESSIONを初期化してはいけません。 $_SESSIONスーパーグローバル変数を用いた セッション変数の登録ができなくなってしまうからです。
これの意味勘違いしてました。
0599nobodyさん2006/10/01(日) 09:31:39ID:???
そもそもネットで個人情報やカードの番号入力する時点でセキュリティが低い。
セッションやSSLに関係なく、個人情報は漏れてるし。
ベリサインも個人情報の流出までは保証してないよ。
0600nobodyさん2006/10/01(日) 09:37:01ID:???
そんなときのPマーク
0601nobodyさん2006/10/01(日) 17:44:25ID:???
SSLは相手の組織の実在証明も大きい
0602nobodyさん2006/10/01(日) 23:27:52ID:???
実在証明の証明書ならね。実在証明無しの証明書も有るし。
PマークもISMSも認証に合格しましたってだけで、漏れない保証は無い。
現場では平気でシュレッダーせずに捨ててたりするし。
0603nobodyさん2006/10/02(月) 04:25:34ID:???
まぁ、SSL通っていてもマーチャントがカード情報を持つようなのは
俺はちょっと引くな。よっぽど大きな企業じゃなければ。
できれば、実績のあるカード決済代行会社を通してる所を使いたい。
0604nobodyさん2006/10/02(月) 13:04:11ID:???
で、実績のあるカード決済代行会社って具体的にどこ?
0605nobodyさん2006/10/04(水) 01:35:01ID:???
ZEROとか?
エロ系サイトでよく見かける大手ww
0606nobodyさん2006/10/04(水) 02:11:06ID:???
10%とか手数料で持ってかれそう(w
0607nobodyさん2006/10/04(水) 15:21:52ID:???
その分価格に上乗せしとけばよい。
0608nobodyさん2006/10/05(木) 01:47:13ID:???
価格転嫁は駄目ってVISAとか指導してたはず。
0609nobodyさん2006/10/05(木) 06:55:51ID:???
むろん、「手数料分を上乗せしてます」なんてわざわざ言うわけないだろバカ。
0610nobodyさん2006/10/06(金) 15:39:05ID:???
すれ違いだろバカ。
0611nobodyさん2006/10/17(火) 09:40:53ID:fxomtaVS
んで結局、「SSLを使わなかったばかりに問題が起きたという実例」ってあるの?
みんな結局、これをしとけば自分もユーザーも安心ってな気持ちでSSLを使用してるんかな?
0612nobodyさん2006/10/17(火) 09:56:15ID:???
>>611
なんでセッションスレで?
0613nobodyさん2006/10/17(火) 13:02:42ID:???
>>611
シラネ

金貰って仕事やってると、クレジットカード決済にSSL使ってません…なんて鼻で笑われるのは事実だが。

SSLを使う一番の理由は、問題が起きる起きないという事よりも、利用者に与える安心感(サイトイメージ)を得る為。
一般人はSSLが何かなんて全く分かってない。
だけど、ベリサインがどうので高度なセキュアをかましてると謳うと、かえってSSLが何かすら
全く分かってない素人には、安心感を与える事が出来る。
SSLを使う理由なんてそんなもん。つまりあなたの仰るとおり。

個人の趣味でやるのなら好きにやればいいし、
金貰ってやるならそれに意味があるかどうかなんて考える必要性は全くない。
0614nobodyさん2006/10/18(水) 03:54:01ID:???
安心感なんて気持ち程度だけどね。
ssl対応でも個人情報ただ漏れの鯖なんていくらでもある。
0615nobodyさん2006/10/18(水) 20:34:34ID:???
やばい、yahooショッピングにセキュリティホール見つけたんだけど
ここで公開するべき?それとも電話かけておしえてあげるべき?
それともメール発射するべき?
0616nobodyさん2006/10/18(水) 20:59:58ID:???
>>615
サイトのセキュリティホールもIPAへの届出でOK
http://www.ipa.go.jp/security/vuln/
0617nobodyさん2006/10/18(水) 21:02:15ID:???
とりあえずここには書くな
0618nobodyさん2006/10/18(水) 21:16:28ID:0wCu4Tq1
やばい、yahooショッピングでアナルホール見つけたんだけど
ここで公開するべき?それとも電話かけておしおきしてあげるべき?
それともホールに発射するべき?
0619nobodyさん2006/10/19(木) 02:53:05ID:???
>>614
そんなの一般人にとっては分からない事だしどうでもいい。

個人の趣味でやるのなら好きにやればいいし、
金貰ってやるならそれに意味があるかどうかなんて考える必要性は全くない。
そこんとこの差が理解できない奴が多すぎ。
0620nobodyさん2006/10/19(木) 06:22:53ID:???
俺はルータにしてたLinuxマシンに、
パケットスニッファを仕込まれた経験がある。
0621nobodyさん2006/10/19(木) 17:10:15ID:???
>>619
日本語でOK
0622nobodyさん2006/10/21(土) 10:06:06ID:???
rootkitとか仕込まれると、怪しいファイルを消してもroot権取られたままで踏み台にされるらしいね。
0623nobodyさん2006/10/22(日) 15:52:50ID:???
Ajax系画面遷移無しの非同期通信で、ポストゲットを使わずにセッションの値を変えられないだろうかぁ〜?
ポストゲットすると変数いじれるし… ボタンを押したイベント時に、セッションの値を代入したいんだよなぁ。
そんなセキュリティーを求められてるんだが… 一日いろいろ試したけど、ポストゲット使う以外の方法が見つからなかった;;
エロイ人教えて;;
0624nobodyさん2006/10/22(日) 17:02:58ID:???
ポストイット使う
0625nobodyさん2006/10/22(日) 19:27:10ID:???
4.4.0でsession_regenerate_id(true)すると古いセッションIDって消してくれます?
0626nobodyさん2006/10/23(月) 18:03:43ID:???
>>625
trueで消せるのは5.1で有効になったから4系では消えない。
0627nobodyさん2006/10/26(木) 06:12:34ID:F7p++raS
PerlとPHPで、sessionの共有は可能でしょうか?

Perlモジュールは CGI::Session を使おうかと思ってます。

SessionIDが同じならPerlとPHPでsessionの共有はできるものでしょうか。

「sessionの共有」する方法をご存知の方、いらっしゃいますか?
0628nobodyさん2006/10/26(木) 06:20:20ID:???
できるできないじゃなくて、
簡単なコードかいて試せば数分でわかることじゃん。
そんな時間ももったいなくて使いたくないのか?
0629nobodyさん2006/10/26(木) 06:50:16ID:???
>>628
ごもっとも。
でも
共有鯖で、Perl用のSessionが組み込まれていないので試しようがない。
モジュールの追加は申請中だけど、いつになるか判らない。 
自宅鯖は、崩壊中。

判んないないら黙っててね。煽るのは止めてね。
0630nobodyさん2006/10/26(木) 08:56:57ID:???
>判んないないら黙っててね。煽るのは止めてね。
何様だ
0631nobodyさん2006/10/26(木) 09:04:21ID:???
どう考えても質問よりテスト環境整えるのが先だろ
0632nobodyさん2006/10/26(木) 10:07:07ID:???
(゜m゜*)プッ
厨に厨が喧嘩売ってんじゃねーよ。質問スレだ、煽る前に答えてやれ。

・PerlとPHPなどでは SessionIDが同じでも、共有はできない。
 CGI::Sessionで、PerlはSessionが使えるけど、それはCGI::Sessionだけで使える。

PHP::Sessionなら出来るらしいが、私は知らない
http://perldoc.jp/docs/modules/PHP-Session-0.15/lib/PHP/Session.pod
0633nobodyさん2006/10/26(木) 10:44:28ID:???
>質問スレだ、煽る前に答えてやれ。
あれが煽りに見える時点でアレだし、この理屈はおかしい
0634nobodyさん2006/10/26(木) 11:03:23ID:???
>>627
俺はperlから離れてはや数年経つしCGI::Sessionは使った事ないが、
PHPに標準実装されてるセッション管理法はファイルベースで、
指定ディレクトリの中にセッションIDを含んだファイル名を使って管理している。

つまり、perlでもそのファイルと全く同じものを使ってセッションを実装するなら、
共有は出来る。それが出来ないなら、自前のセッション管理法にすればいい。
0635nobodyさん2006/10/26(木) 11:05:50ID:upDRXWKA
ログインフォームからログインしてセッションでtime()使ってタイムアウトさせるようにしたんですけど、
今のままだとログイン後に設定した時間が来たらタイムアウトされます。

何かしら操作したら情報をリセットするようなことってできますでしょうか・・・。
0636nobodyさん2006/10/26(木) 12:07:11ID:dpAXN0uK
>>634
そうなんだけど、PHPのセッションハンドラって指定できなかったっけ?
デフォルトはファイル管理だと思うけど(サーバー設定次第)DB管理にもできるし。
DB管理にしちゃえばPerlの共有前提なら楽チンだと思った。
まぁ、いずれにしよ、モジュール任せの実装じゃ共有は難しいね。
0637nobodyさん2006/10/26(木) 13:56:19ID:???
>>636
出来るよ。
session_set_save_handler()使うのが楽。

>まぁ、いずれにしよ、モジュール任せの実装じゃ共有は難しいね。
そういう事。

>>635
PHPのデフォのセッション使ってるなら、タイムアウトの指定が出来るから確認してみ。
0638nobodyさん2006/10/26(木) 18:24:54ID:???
php5.2でセッション使ってる人の感想聞きたいのですが、
php5.1とくらべて何か変わったところありますか?
0639nobodyさん2006/10/26(木) 23:01:05ID:???
ない
0640nobodyさん2006/10/26(木) 23:29:44ID:???
そろそろ5.2がインデックスにでてくるころじゃね。
でもなんでベータ版ってわかりずらいところにおいてあるんだろう。
0641nobodyさん2006/10/27(金) 16:29:50ID:qVqOzfjK
>>637
ありがとうございました。解決しました。
0642nobodyさん2006/10/29(日) 07:44:54ID:???
馬鹿がダウンロードしないようにでしょ。
バカ避け。
馬鹿は安定板を使うべき。

セッションが簡単に共有できたら、レン鯖なんてセッション取られまくりだ(w
つ他人のセッション
0643nobodyさん2006/11/03(金) 13:21:11ID:QUVcMJYR
そもそも、セッションIDがばれたら何が怖いんですか?
どこをどうされてログインされるんですか?

こないだセッションIDというヤツを他人に知られたんですけど、
何をされるんですか?
0644nobodyさん2006/11/03(金) 14:19:12ID:???
ググって自分なりに調べたらまたきなさい。
あげんなバカ
0645nobodyさん2006/11/03(金) 14:37:00ID:???
>>643
初級ネット
http://pc8.2ch.net/hack/
0646nobodyさん2006/11/04(土) 01:54:01ID:toBPKG6d
セッションの有効期限なのですが

session_cache_expire(1440); //12時間
session_start();

セッションが必要なページ全てに書いているのですが
途中で切れています 12時間持ったことが今までないのですが、
なにか注意点はありますか?
0647nobodyさん2006/11/04(土) 04:42:40ID:???
その関数はHTTPのキャッシュコントロールで
セッションの有効期限とは関係ないと思うけど
0648nobodyさん2006/11/06(月) 03:28:19ID:???
質問者ではないけど、キャッシュコントロールと有効期限とは別物なんですか?
ちょっと気になったもので。
0649nobodyさん2006/11/06(月) 04:45:28ID:???
>>648日本語でOK
0650nobodyさん2006/11/06(月) 08:25:11ID:???
1440分って24時間だけど
0651nobodyさん2006/11/06(月) 08:28:14ID:???
session_cache_expire(12*60); //12時間
にしたらよかったのに
0652nobodyさん2006/11/07(火) 10:39:00ID:???
>>646
セッションの有効期限は
session.gc_maxlifetime
session.cookie_lifetime
前者はサーバ側でのセッション保持期間、
後者はクライアント側でのセッションID保持期間。

>>647
キャッシュが有効だとサーバ側で予測できない遷移が起こってしまう。
セッション中ではその予測できない遷移によって、セッション変数に不整合が生じるなど、
悪影響がでる可能性が増大する。
そのため、セッション中におけるキャッシュの制御を、
通常のキャッシュ制御とは別にセッション関連の設計者・プログラマにゆだねる必要がある。
session_cache_expireはそのための関数であって、セッションの有効期限とは無関係。
■ このスレッドは過去ログ倉庫に格納されています