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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

無理

そこをなんとか

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

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

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

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

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

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

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

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

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

sessionと何が違うんだ？

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

>>519
？？？

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

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

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

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

どうして？？

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

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

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

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

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

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

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

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

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

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

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

じゃそういうことで。

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

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

そんなセッションな、

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

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

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

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

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

ないだろｗ

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

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

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

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

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

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

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

セッションでメモリリークの次はこんな話題かｗ
本当レベル低いよな。

そもそもSSLの是非を問うスレじゃないんだが…