アカウント名:
パスワード:
方法 B: 2つのクッキーを使い分ける サイトの設計上、http://... の画面と https://... の画面をまたがってセッション管理を行う必要がある場合は、2つのクッキーを発行し、一方を secure 属性付きとし、もう一方を secure 属性なしとします。https://... の画面ではセッション管理に前者のクッキーを使用し、 https://... の画面では後者のクッキーを使うようにします。 このとき、暗号化で保護が必要な画面(https:// を使うことにした画面)に対して、http:// でアクセスされても情報を表示しないように作る必要があります。そうしないと、攻撃者は、盗聴で盗み出し
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
「2つのクッキーを使い分ける」ってのがねー (スコア:2, 興味深い)
Re:「2つのクッキーを使い分ける」ってのがねー (スコア:1, 参考になる)
暴言かましてよかですか? (スコア:2, 参考になる)
>つまり,コンテナが管理しているセッションIDとは別に,セッションID を管理してあげればよいのです。
面 倒 臭 ぇ
…いや、まあ、その、あなた様の意見は正論です、その通りです。返
Re:暴言かましてよかですか? (スコア:0)
いや、むちゃくちゃな納期でデスマーチになってたり、キッチリやっても評価してくれる人がいなかったり、というのはわかるんですけどね・・・。
もっとも、「ブラックボックスで使え」と提供されているものに対して問題点を理解してさらに適切に対処できる人ってきっと少ないんだよな・・・。問題点や対処方法はわかっていても、神の声で気づかなかったことや仕様扱いにさせられるとか・・・ね。
Re:暴言かましてよかですか? (スコア:1)
ブラックボックスというか、「フレームワーク」と呼ぶものなんでしょうね。
問題は、そのフレームワークの「ホットスポット(改造予定個所)」が
適切に用意されているかどうか、なんですが…
たしかにJavaServletのあのcookieを初めて見たときには、
ちょっと首を傾げたもんでした。
「なんで変更するメソッドが無いんだろう?」って。
まあ、そのうち改善されてくれることを期待します。
Sevlet APIも、時と共に少しづつバージョンが上がっているわけですから。
少なくとも全くの無神経ってことは無いようですよ。
たしか以前にも、ヨソのセッションに属するObjectをアクセスできちゃうメソッドが廃止になった
という改良が有ったような記憶が。
#そもそもそんなメソッドが最初から有るのが変だ、とも言えるかもだが。