アカウント名:
パスワード:
セッション管理は必ずしもcookieが必要ではないですよ。cookieを使うと作る側が便利だったり、楽ってだけで。
大手ISPのユーザー設定(料金コースやオプション)で、SSLだけでセッションを維持してるとことかありますよ。
M1達はほんとにセキュリティの基礎がわかってるのか??
どうせ、cookieやHTTPなセッションもタイムアウトがあるんだから、keep-aliveしてTCPをHTTPなセッションの代わりにしたほうが美しい仕様だと思っています。 telnetも、FTPもTCPが切れたらお終いでloginやり直しだから、HTTPで買い物していてもkeep-alive(TCP)が切れたら、ログインし直しで納得出来そうです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
cookieを弾くと危うい (スコア:3, 参考になる)
インタラクティブなWebサイトを作る上でセッション管理は必須の要素で、セッションキーは必ずどこかで持ち回る必要が生じます。
Webアプリケーションを作るためのほとんどのフレームワークも、セッション管理を自動できる機能を提供しています。
通常はセッションキーをcookieに持たせるのですが、cookieが利用できない場合に多く利用されるのがURLへのセッションキ
Re:cookieを弾くと危うい (スコア:-1, オフトピック)
セッション管理は必ずしもcookieが必要ではないですよ。cookieを使うと作る側が便利だったり、楽ってだけで。
大手ISPのユーザー設定(料金コースやオプション)で、SSLだけでセッションを維持してるとことかありますよ。
M1達はほんとにセキュリティの基礎がわかってるのか??
Re:cookieを弾くと危うい (スコア:2, 参考になる)
SSLのセッションはkeep-aliveと同様に時間切れを起こします。クライアント証明書でも使っているのですか?
もしかして、そのISPの接続元からしかログインできないシステムですか?
Re:cookieを弾くと危うい (スコア:1)
IPのバラバラなパケットを連続した通信に見せるためにTCPを使ってますよね。
せっかく、TCPで連続した通信になったのに、TCP上のHTTPでGETとかPOSTで通信が終わるたびにTCPをcloseしてしまっています。
closeした後、前と同じ人が、GETやPOSTしてもサーバからは同じ人のアクセスかどうかがわからなくなるからcookieを使ってHTTPなセッションを作って連続したアクセスだと認識しています。
どうせ、cookieやHTTPなセッションもタイムアウトがあるんだから、keep-aliveしてTCPをHTTPなセッションの代わりにしたほうが美しい仕様だと思っています。
telnetも、FTPもTCPが切れたらお終いでloginやり直しだから、HTTPで買い物していてもkeep-alive(TCP)が切れたら、ログインし直しで納得出来そうです。
今となっては、過去の資産があってしかたがないのは納得しています。
# keep-aliveをHTTPなセッションの代わりに使うとproxyが難しそう。。。
Re:cookieを弾くと危うい (スコア:0)
Re:cookieを弾くと危うい (スコア:0)
むしろ、Basic認証でログインしてます・・・ってオチだったりして?