11

ユーザーが初めて私のサイトにアクセスしたときに、jsessionidセッション情報をCookieに依存するのではなく、Wicketで生成されたURLにが含まれていることに気付きました。

Cookieは正常に設定され、ユーザーが単にページをリロードするjsessionidと、URLに追加されなくなります。ここでこれをテストできます：pixlshare.com。画像リンクのいずれかにカーソルを合わせると、jsessionid;が付いたURLが表示されます。ページをリロードすると、jsessionidsが削除されます。

Wicket SEOページの以前の経験から、ボットからそれを隠すためにを削除する方法を知っていますjsessionidが、通常のユーザーにこの手法を採用することはハックのようです。それはまた、クッキーを無効にするのに十分な妄想的な人々のためにサイトを壊します。

これは、GlassfishからTomcatに最近移行した後に発生していますが、それが原因であるかどうかは定かではありません。また、Tomcatの前でApacheのmod_proxyを使用しています。

4

1 に答える 1

19

何が起こるか：クライアントは初めてページを要求し、Cookieをまったく送信しません：

$ curl -v http://pixlshare.com/upload

サーバーは、この要求に基づくクライアント機能、特にCookieをサポートしているかどうかについては何も知りません。したがって、安全性を高めるために、CookieとエンコードされたURLの両方を送信します。JSESSIONID

< Set-Cookie: JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C; Path=/; HttpOnly
...
<a wicket:id="image1Link" href="gallery/OKfzVk;jsessionid=25E7A6C27095CA1F560BCB2983BED17C">

JSESSIONIDつまり、クライアントがCookieをサポートしていない場合に備えて、サーブレットコンテナはすべてのURLに防御的に追加します。

では、なぜJSESSIONID2番目のリクエストで消えるのですか？これで、クライアントはHTTPリクエストでCookieを送信し、サーバーはCookieを処理することをサーバーが認識しているためです。そうは言っても、JSESSIONIDもはや必要ありません。

$ curl -v -b JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C http://pixlshare.com/upload
> Cookie: JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C
...
<a wicket:id="image1Link" href="gallery/OKfzVk">

一方、クライアントがCookieをサポートしていない場合、サーバーは引き続きURLを書き換えます。

これはWicketの問題ではなく、Tomcatの機能です。

ところで（あなたのウェブサイトのJavaScriptから）：

path = path.replace(/^C:\\fakepath\\/i, '');

何の偽物？

于 2011-07-24T17:29:23.693 に答える