アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
たとえば (スコア:1, すばらしい洞察)
cookieそのものを禁止されたとして、ますますJavaとかの利用に拍車がかかるかも知れませんね。
それはそれでまた、面白い話かもしれないし、ビジネスチャンスとも見える。
Re:たとえば (スコア:0)
って、JavaはクッキーもURLも使わずに同一ユーザからの接続って認識できちゃうんですか?
Re:たとえば (スコア:2, 興味深い)
Re:たとえば (スコア:1)
>Javaだと、単にクライアント側でアプリケーションが走らせることができますから、あとは独自プロト
>コル over HTTPをすればOK。
それでは問題解決にならないのでは?
Cookieだけでも不安なのに更に鯖が提供する中身不明のクライアントアプリまで
動かすことを許すんでは、却って悪いのではないかと。
クライアントのJavaをSandboxに入れることで安全が得られる(=Applet)、というなら、
なんてゆーかよくわかんないけど、CookieのようなものもSandboxに入れれば
いいんじゃないのかな。
StatefulなSessionをそれ自体が持つProtocolはそれこそ辛いだろうから、
Stateless protocol+クライアント(=ブラウザ)に勘合符Objectを持たせる、
っていう構図は変えなくていいかなと。
確認の必要性 (スコア:1)
問題なのは、ユーザーがそれと意図しないうちに、Cookieを設定し情報収集されること。要するに、disclosureが足りないってこと。
明示的なログインを要求すれば、ユーザーへの意志確認になる。技術的にどうこう、がわからなくても、自分の意志でログインしたって点だけは明らかになる。
だからと言ってログイン後は好き勝手していいわけじゃないけど、そういうプロセスは必要、ってことだと思います。
Re:たとえば (スコア:0)
>Cookieだけでも不安なのに更に鯖が提供する中身不明のクライアントアプリまで
>動かすことを許すんでは、却って悪いのではないかと。
それこそ、オープンソースで開発すればいいのでは?
自分では自身がないので Anonymous Coward なんですが。
Re:たとえば (スコア:1)
>それこそ、オープンソースで開発すればいいのでは?
「なにを」作れって言うんですか?
要件を満たすものを作ることが「技術的に」可能かどうか?が問題だと思うのですが。
まぁHTTPやTCPに替わる全然違うものを(Openで)作って解決する、という手は
きっとまだ残されているんでしょうけど。
>自分では自身がないので Anonymous Coward なんですが。
関係ないだろうに…
この世がすべて「言い出しっぺの法則」で動くのが是だとしたら、
それはそれで窮屈で困る世の中っすよ。
Re:たとえば (スコア:1)
platformはasp? cgi? php?
aspならsessionでイケませんか?
cgiなら、最初に環境変数を極限まで取り込んでマージしてサーバーに保存。
後はユーザーからリクエストがあった際に比較する。
で、商品購入等の処理が一通り終わったら情報を消去。
ユーザー環境(OS)等を見れば、短期間で変化する事はまずありませんから
大丈夫だと思います。
getで送る方法もありますが、万一refferが漏れますと危険ですから
推奨はしません。
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が無くなるだけでこれだけの不便と苦痛ができるワケです(笑
利用者の側に立って、物事を考える必要がありますね。
Re:たとえば (スコア:0)
アプリケーションサーバでは、
SessionBeenを端末と結びつける機構があって、
ある端末からのメッセージは、その端末の
SessionBeenオブジェクトを持って通知される。
で、その機構とは、、、、、
Re:たとえば (スコア:2)
などなど電気会社の大手は、8台前後のProxyを設置しておられます。一定時間、IPアドレスでクライアントを特定しておくというのは、無理があります。
Re:たとえば (スコア:1)
クライアントがDHCPな世界だと、もうアウトじゃないっすかソレ。
いわゆるプロバイダ経由で接続することを考えると、
そのwebアプリの対象ユーザー層次第で
DHCPユーザーのほうが多数派になっちゃったりしますよね。
え?その機構ってまさかJavaServlet(つーかJ2EEでEJB)な世界「一般」の話じゃ
ないですよね?ね?ね?
Servlet初心者なんで不安になってしまう俺。
Servletの HttpSessionクラスの説明はここ。
あう。あのクラスが勝手に全部やってくれるんで意識してなかったなあ。
初心者(=成果物が「まだ」無い段階)で良かったのかも。