3

Java EE 標準に従って、Tomcat では、リクエストで既存のセッション ID を次の 2 つの方法で指定できます。1) Cookie を使用する方法。2) 「パス パラメーター」経由 (通常のパラメーターではありません。パス パラメーターには次の形式がありますhttp://host/path/file.ext;jsessionid=xxx?a=b&c=d...。「;」と、クエリ文字列がパス パラメーターの後にのみ開始されることに注意してください)。私が望むのは、「?」の後のクエリ文字列で、リクエストのセッション ID を REGULAR パラメータとして渡すことですhttp://host/path/file.ext?jsessionid=xxx。

リクエストがインターセプトできる場所に到達し、コンテナがセッション ID を決定する方法を (フィルターやサーブレットなどで) 変更できるようになるまでには、手遅れです。変更したい動作は、クライアントからの要求の初期処理にあります。私が避けたいのは、Coyote または Tomcat のコードを変更し、Tomcat を自分で再構築することです。これには明らかな理由があります。私がやりたいのは、適切なコードをオーバーライドし、そのコードを使用して要求されたセッション ID を判別するように Tomcat を構成することです。それは不可能に思えますが、私が間違っていることを願っています。

この方法でセッション ID を取得することは標準的ではありません。Cookie またはパス パラメータを使用することは、セッション状態を追跡するための優れた方法であることを知っています。セッション ID を実際のクエリ文字列に入れると、それ自体が潜在的な問題を引き起こすことはわかっています。とにかくやるしかない。

Tomcat 7を実行しています。

4

2 に答える 2

1

最も簡単な方法は、Tomcat をソースからビルドし、CoyoteAdapter.java クラスをハックすることです。

これはこのコードが存在する場所ですが、要求パイプラインのこの部分をインターセプトするためにコードを少しプラグインするだけで簡単に拡張できるコードの部分ではありません。

「その場で」ハッキングするのではなく、独自のCoyoteAdapterに依存する独自のコネクタを賢く実装することもできますが、最終的には、更新に追いつくなどのメンテナンスの問題が残ります.

通常、リクエストパラメーターは何かが要求するまで「解析」されず、通常、これは実際のユーザーコードまで行われないため、注意する必要があります（ユーザーコードをヒットする前にパイプラインで行われるとは思わない） .

これは重要です。GET の場合、パラメーターの解析は要求ヘッダーから行われますが、POST の場合はコンテンツに基づいているためです。また、リクエストにパラメーターを要求すると、それが POST であるか GET であるかを気にせず、自動的に「正しいことを行います」。

つまり、POST からリクエスト パラメーターを要求すると、パイプラインは、ユーザーのアプリケーション コードの前に入力ストリーム (ヘッダーの後のリクエスト ペイロードを指し始める) を消費します。ユース ケースによって異なりますが、生のストリームが必要なアプリもあるため、生の URL 自体を操作するのではなく、組み込みの要求パラメーター ロジックを使用する場合は注意が必要です。

単純なフィルターを使用してこれを回避することもできます。次に、HttpServletRequest を基になる Tomcat 実装 (現時点では名前がわかりません) にキャストし、その上で「setSessionID」コードを呼び出すことができます。それが処理サイクルで遅すぎるかどうかはわかりませんが、そうかもしれません。

したがって、実際に規定された拡張手段を介してではなく、むしろ単純に見えるかもしれません。正式な方法は、Tomcat コネクタを複製して独自のバージョンの CoyoteAdapter を呼び出し、それを server.xml で構成することです。しかし、Tomcat の独自のバージョンを維持したい場合は、CoyoteAdapter を直接ハッキングする方がはるかに簡単です。

于 2013-08-18T21:34:58.287 に答える