それは自業自得だからしょうがない。
ネカフェでミクシなんてあり得ないでしょ。

個人情報漏れまくりだ。

いやぁ、mixiだからこそ十分ありうるぞ。
だってPCに詳しくない女性とかライトユーザが超多いから。

。。。
「次回から自動的にログイン」のチェックを入れてログインしないと、そんな事にはならないでしょ。
当たり前の実装が普通にしてあったぞ。

>>403
ハァ？？
「次回から自動的にログイン」にチェックを入れなくても
ログインが継続される仕様になってるから>>398のような疑問が出るわけだが。

今、俺が実際に実験してみたところ、「次回から自動的にログイン」をチェックせずに
ログインした状態でパソコンを再起動してもログインが継続されていた。
すなわちネカフェなどでの使用は超危険。

それは不思議だな。俺の環境では普通にブラウザ閉じた時点でログアウト。XP SP2+IE6
http://mixi.jp/help.pl#10dこうも書いてあるし、バグレポ送ったらｲｲﾝｼﾞｬﾏｲｶ。

正直、そんなバグあったら界隈で大騒ぎされているとおもうが。。

送られてくるCookieを見ると、次回から自動的にログインに
チェック無し
→有効期限無し＝セッション限り
チェック有り
→有効期限2011年5月28日

再起動後もログインが継続されるとすると、ブラウザ側に問題があるが、
そういうブラウザがあるなら気をつけた方が良いな。

↑はmixiの話です。

２ちゃんねる系ブログが続々と閉鎖・炎上！
現在進行形で祭り中

資料４（最新版）　http://myon.blog.shinobi.jp/Entry/4/

セッションに詳しくないミクシ住人が、「次回から自動的にログイン」のチェックの危険性なんて理解できる訳ないじゃん。
便利だからって理由で「次回から自動的にログイン」にチェック入れてるでしょ。例え不特定多数が使うPCでも。

そもそも外ならたいてい携帯使うんじゃない？

>>402
俺もIE6なんだが、、、バグだろうか？？
「自動ログイン」にチェック入れなくても、
ブラウザ閉じようがPC再起動しようが、ログイン状態が継続されてるよorz

みんなそうだと思ってたら、俺だけなのか・・・

↑
ごめ、>>402じゃなくて>>405へのレス。

今、自分mixiのクッキーを調べてみた。
「自動ログイン」のチェック無しでログインすると
「BF_SETTING」って項目とデータ７行。

「自動ログインあり」だと、「BF_SETTING」に加えて、
「BF_SESSION」と「BF_STAMP」ってのが追加されるみたいだね。

>>411
チェック外しても昔送ったクッキーを生かしたままにしてあるとか？

>>414
少なくとも、ログイン画面を見ているときはクッキーが切れてる。

>>414
どうやって生かしたままにするの？？

むしろログアウト判定のクッキー喰わせてる訳か。ダサイ設計だ。
ログアウトしてるのに、クッキー消したら認証突破できるんじゃね？

>>417
ん？　何を見当違いのこと言ってんだ？
「ログアウト判定のクッキー喰わせてる」って、何を根拠に言ってんだか・・・

>>417
ログアウトは、有効期限切れのクッキーを送ってる。
つまり、クッキーを削除するのに通常使われる方法だぞ。

>>419
だよね。

Ｄ　Ａ　Ｙ　Ｏ　Ｎ　Ｅ

SO YA NA

O YO NE

O YO YO

「だよねー」はねーよ だ！

ﾊﾞｰﾛｰｗｗｗｗｗｗｗｗｗｗｗｗ

あるwebアプリの開発を引き継いでるんだけど、検索結果とか一覧で同じ表示形式（ページングとカラムごとのソート機能付き）を共通で使いたい。
なおかつ、結果と、ソート状態、何ページ目は、他のページを開いても戻って来た時保持したい。
いちいちGETやPOSTからsqlクエリを毎度生成するのはめんどくさ過ぎるから、
検索条件が投げられた時点でsql文をつくって、まるごとセッションにぶち込む。URLにGETに含めるのは現在何ページ目、ソート対象、ソート方向、表示件数だけにしてしおうかと思ってるけど、こういうのはありなのかな？

>>429
2枚ウインドウを開いて違う検索しようとしたら、一方の検索条件が両方に適用されて
まともに使えないサイトがあった。
ウインドウ毎に区別されるようにしてね

>>430
暫く前の@type(転職サイト)がそう。最悪の使い心地だった。
今は他社同種のと同程度には改良されてるけど。

>>430-431
なるほど。そういう弊害もあるのか。
いい事聞いた。ありがと。
やはり自分で想定できることってかぎられてるんだなと。
だったら新たに窓を開いたら窓ごとに別のセッションネームをつけてsql文を格納すればよさそうですね。
表示部分の関数がsql文をわたす設計で、結果からのリンクはすべてget渡しなんで、関数内でsql文を生成するとおそろしく面倒なことになりそうだ。

使い回ししやすいように関数化して、ダブらないように独自のセッションネームを吐くようにしてるけど、けっこう苦戦中。
でもこれが完成したらすげー楽になるかも。

ｶﾞﾝｶﾞﾚ

だめだ。検索掛けるときにgetで投げるときもあれば、postでやるときもあるし、selectのonchangeつかって同時にget投げるときもある。
全ての入力を統合するのは、やっぱり無理っぽいかも。もう限界に近づいて来たというのに、ひどい状態になってしまったorz
コメントアウトだらけで自分でもわけわからん、

一方ロシアはSQLをその都度生成していた

おそロシア

会員制サイトのログイン状態の保持にセッションを使ってるのですが
アイドル状態が続くとセッションが切れてしまうのを
回避する方法を考えています。

・ サーバでのセッション保持期間を長くする
・ セッションでなくクッキーなどによる管理に変更する

これ以外になにかいい方法があったら教えてください

>>438
普通に考えたらクッキーだよな。

面白い方法だと、例えば幅無しのフレーム作って、そっちのフレームの中を<META>タグで
何秒か置きに更新させて、その中でセッションを更新させてやるとか。
↑まぁこんな事やる意味が分からないけどね(w

>>439
フレームはちょっと考えてました。
あとはFlashとかで定期的に通信するとか。
でも最後の手段と考えてます。

クッキーの場合は、パスワードも暗号化したクッキーとして
クライアントに返して
毎回そのクッキーで認証するって感じでしょうか？

>>440
「毎回」の意味が不明だけど。
認証に通ったらワンタイムパスワードを発行。

セッション保持はメモり喰うし、メモリリークが発生しやすい。
クッキーやワンタイムパスワードは総当たり攻撃で突破される。

そもそもHTTPなんてステートレスなプロトコルでセッションが切れるのは仕様。
SOAPとかCORBAとか他のプロトコル使ったら？

>>438
＞アイドル状態が続くとセッションが切れてしまう

session.cookie_lifetimeが「0」なら、
ブラウザを閉じない限りセッションも切れないだろ。
しかもそれってデフォルト設定だし。

>>443
サーバ側は削除されるだろ？

>>444
削除されないよ。
実際自分のとこで動かしてるスクリプトは、
一度ログインしたらブラウザ閉じるまで何日でもログイン状態（＝セッション）続いてるし。

ブラウザがセッション切る場合もあるし、間に入ったNATやプロクシが切る場合も有る。

何日もログインできるってメモリリークしまくりに気づいてないだけじゃ？

>>446
お前が>>442で書いてることは間違い。
セッションはファイル（またはDB）で管理されるものであり、
メモリとは直接関係ない。したがってメモリリークなど起きない。

悔しかったら具体的にどういう根拠でメモリリークが発生するか書いてみたまえｗ

>>445
他にアクセスがなければ削除されないでしょ

自分しか使わないシステム？

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

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