アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
たとえば (スコア:1, すばらしい洞察)
cookieそのものを禁止されたとして、ますますJavaとかの利用に拍車がかかるかも知れませんね。
それはそれでまた、面白い話かもしれないし、ビジネスチャンスとも見える。
Re:たとえば (スコア:0)
って、JavaはクッキーもURLも使わずに同一ユーザからの接続って認識できちゃうんですか?
Re:たとえば (スコア:1)
platformはasp? cgi? php?
aspならsessionでイケませんか?
cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
後はユーザーからリクエストがあった際に比較する。
で、商品購入等の処理が一通り終わったら情報を消去。
Re:たとえば (スコア:1)
そのsessionという上位概念を実現するために必要な下位概念つーか道具は何か?
という話だったんじゃないでしょうか?
sessionを実現するために、Cookieを使ったり、他の技術を使ったり…と。
>cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
>後はユーザーからリクエストがあった際に比較する。
クライアント側からは幾らでも捏造可能だったり、
逆にサーバー側から見たらWinのActivation並の邪悪さだと見なされるものだったり、
しませんかそれって?
Re:たとえば (スコア:1)
> という話だったんじゃないでしょうか?
aspについてはすいませんでした。
その通りです(^^;
> >cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
> >後はユーザーからリクエストがあった際に比較する。
> クライアント側からは幾らでも捏造可能だったり、
> 逆にサーバー側から見たらWinのActivation並の邪悪さだと見なされるものだったり、
> しませんかそれって?
ええ、します。
あくまで技術的には可能というだけのモノですね。
特にサーバーから見ればかなりの悪です。
ただ、現実的に考えますと環境変数から
REMOTE_ADDR,REMOTE_HOST,HTTP_USER_AGENT,HTTP_REFERER,
これらを適当にマージしcrypt比較したものでセッションの確認をすると仮定しますと、
他のクライアントからリアルタイムに捏造するのは、かなり困難では?
(パケット通信は省きます)
勿論この方法は、サーバー上で認証をかけてDBにアクセスするようなモノでは
危険ですので利用する事はできません。
ただ、DBを利用しない簡易ショッピングカート(一回限りで注文内容をメールで送信)や
ツーショットチャット等ならそれなりに利用できると思います。
個人的には他の方の書かれていましたJava利用するなり、独自プロトコルover httpが
良いと思います。
というわけで、Cookieが無くなるだけでこれだけの不便と苦痛ができるワケです(笑
利用者の側に立って、物事を考える必要がありますね。