む、難しいな orz

大丈夫、実際そこまでちゃんと気ぃ使ってるサイトなんてほとんどないからw

素で知らんかった。マジありがとう。

>>158
データの内容とアクセス頻度(規模)などによって一概にどっちが良いかは言えないし、
「良い」の基準が決まっていないとレスのしようもないんじゃない？

例）
・作成時に楽なら良い
・サーバー負荷を考えると良い
・セキュリティ的に安全だから良い
などなどなどなどなど・・・。

セッションの前に他のことを勉強しろよ。斬り。

ヒロシです

きれいに返されました。
セキュリティ・負荷面を重視しています。
よろしこです。

ヒロシです

PHPでセッションを使って管理ページに入りページの更新やメール配信などをしています。
使用人数は10人です。
ＯＳは基本的にwindowsでバージョンはＸＰや98など様々です。

ページの更新などをする際に5分くらいでセッションが切れます。
ほぼ10人ともその状態です。

セッションが頻繁に切れる原因とかってありますか？
漠然とした質問で申し訳ないでつ。。

Perlのセッションについて語るすれはどこですか？

このスレだけでご飯一杯食べれました。

食前酒みたいなスレやなｗ

ヤフーのセッション管理の仕組みって、どうなってるんでしょうか。
ページ移動するたびにDBにアクセスしてCookieと照合してます？

セッションで扱いたいクラスそのものをシリアライズして、セッションIDをKeyにし、
DBへ登録して使っている人って結構いる？
それともメモリー的にとか、DB容量的にとか、処理的に冗長だとかで、むしろ無駄？

Perlで固定のリクエスト投げるHTTPクライアント作ってるのですが、
返ってくるセッションクッキーをどうにかしてブラウザに食わせたいと思ってます。
firefoxのクッキーファイルに書き込むだけではだめでした。
expires付のクッキーはうまくいくのですが…
これを解決する手段はないものでしょうか？

Perlかどうかはどうでもよく、セッションクッキーの話なのでこちらに書き込みました。
もしもっと適切なスレがあれば是非教えてください。

>>169
どうも混乱しているようにしか見えないのだが…
HTTPクライアント作ってるって時点で「板違い」

セッションクッキーってのも意味わかんないし、
まずはセッションは何たるか、クッキーは何たるかを理解してから出直してね。
もしくは169の認識してる「セッションクッキー」と「クッキー」の違いを言ってみ。

>セッションクッキーってのも意味わかんないし
確かに「セッションクッキー」はセッションと言うにはアレかも知れんが、
簡易なセッションを実現するものではあるし、
なにより、みんな「セッションクッキー」って呼んでるじゃん。
で、普通、「セッションクッキー」に対して、単に「クッキー」って呼ぶのは、
「パーマネントクッキー(169曰く、expires付のクッキー)」でしょ。

>>169
セッションクッキーで通じるから別にいいけど
確かに用語の使い方がいろいろ不明な点があって
日本語として文が構築されてない

会員制のサイトつくるとき
セッションIDだけで管理してる？
セッションIDだけだと怖いので
ログインIDと暗号化したパスワードも
セキュアクッキーに書いて
毎回DBと比較してる。
これってやばい？

>>173
やばくはないと思うが
それじゃセッションIDを使う意味があまりなくね？
セッションIDの発行方法にもよるけど
PHPのセッション関数使ってるなら大丈夫じゃないの？

>>174
レスありがとうございます

ログイン前の匿名情報（ショッピングカートのようなもの）を
セッションIDで管理、
ログイン後の情報はセッションだとちょっと怖いので
セキュアクッキーでアクセスの度に毎回ログインチェックをしてます。

セッションIDだけで
クライアントを特定するのって
会員制のようなサイトでも普通なんでしょうかね？

>>175
個人的な構築法としてはセッションIDとログイン情報を関連付けて
セッションIDきたらログイン情報みて毎回チェックするけど
規模がデカイ or サーバしょぼい　場合は毎回チェックするとレスポンス落ちるから
Yahooみたいに重要な処理のときだけログインチェックみたいな形にしてる

けど173のケースだとログイン前からの情報とも連携するみたいだし
それならセッションIDとcookie使ってても納得できる

毎回ログインチェックするのに越したことはないけど
やっぱりサーバのスペック的な問題でレスポンスが結構影響でてくるから
重要なページ（個人情報変更）とかだけ認証っていう形でもありじゃないかな？

良いセッションの使い方があれば他の人フォロー頼みます。

PHPセッションを生成した段階で、接続元IPを保持すれば、少なくとも
全く異なるネットワーク＆端末からの接続は排除できる。
(ＮＡＴ環境とか一部のＣＡＴＶ環境からのアクセスはどうしようもないけど)。

で、その上でブラウザバージョンとか「相手から送られてくる情報」を、
『セッション単位のワンタイム情報』として管理すればかなりいけるんでない？

まぁ、金銭扱う場合は「やりすぎ」ってのはないだろうけど、使う側の利便性を
考えればワンタイム情報として上記を扱う(＋独自のスパイス)でほぼ安全でしょう。

>>176
やっぱりサーバ負荷は一番気になるとこですね。
たいへん参考になりました。
ありがとうございました。

>>177
大企業などアクセスのたびに
毎回IPアドレスが変わる環境もあるから
だめじゃないかな？

>>178
> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？
そんな場合、HTTPに限らず他のサービスでも認証が絡む奴は
大問題になりそうな希ガス...

気のせい？

>>179
IPで認証するの？

>>179
そういう仕組みですから
みんなそれを前提につくってるんだよ

>>179
今更何を言ってるんだ？

そっか、世間ではFTPとかtelnet/sshとか、そんな奴にもクッキーセッションみたいな
「IPが変わってもサービスを継続する」実装が結構あるんですね。
確かに作っちゃえば可能だなー＞セッション管理

ちょっと遊んでみよう(w

>>183
FTPとtelnet/SSHはステートレスなプロトコルではないので
セッション管理自体要らんと思う

>>184

>>178
> >>177
> 大企業などアクセスのたびに
> 毎回IPアドレスが変わる環境もあるから
> だめじゃないかな？

アクセスの度に変わるんだぜ?
Connection張りにきたからってACK返そうにも
すでにIPアドレスが変わっているんだぜ？

って、釣りか....>>178

>>186
それじゃインターネットに繋がってるだけで送受信できないし
ACK返す前に変わるとかそんなシステムあるの？

1回セッションした後でIP変わってもう一度セッションしたときに
どうなるかだろ
そもそも接続元IPを使ってどーのこーのって
今の時代に使ってるところないだろ

>>187
セッション汁！？

>>186
なんかかみ合ってない。
どういう意見なの？
できればはじめての発言でないなら前のレス番使ってくれ。

>>188
その回答は>>178だけが知っている。
「毎回IPアドレスが変わる環境」の“毎回”って何よ？

http://yougo.ascii24.com/gh/79/007983.html
黙って読め

>>189
もしかして
「ダイアルアップする度の間違いだろ」
とか思ってないよね？ｗ

>>190
「アクセスの度」っていう「アクセス」の定義が不明なんじゃない？
セッションはその通りだけど、PHPのセッションとはまたちょっと違う気がする。
HTTPセッションが切れても状態を引き継ぐための一例としてPHPセッションが
有るんじゃないの?

>>192
セッションが切れてない間は
IPアドレスが変わらないって言いたいの？

なにが言いたいのか
結論を書いてくれないと
話しが終わらないんだけど

>>193
さっさと話を終わらせてくれって言いたいの？

ならそう言えよ

>>193
逆でしょ？
「IPアドレスが変わっても(サービスのために)セッションを切らない」
為の仕組みが「PHPセッション」な訳ですよ。

つか、「セッション」の定義を表現せねばなるまいね。
IPセッションなのか、HTTPセッションなのか。

>>195
激しく同意！

ってかセッションってWEBでのセッションはHTTPセッションで
PHPセッションとかってセッション管理だろ
Perl=CGIみたいな初心者的勘違いだな

けど>>186とかACKが帰ってくる前にIP変わるわけだから
これはセッション自体成り立たない

>>192
それはセッション管理だろ

どれがだれの発言なんだか
全くわからん
1人の自演だったらすごいけど

ここにはｵﾚとｵﾏｲしかいませんよ？

>>198
よかった、一人じゃなかったんだ

少なくとも３人いるな(w