私はついにアプリをapache/mod_jk負荷分散を前にした2インスタンスのシングルノードテストクラスターにデプロイしました。
非クラスター化環境では、JDBCRealmでコンテナー・セキュリティーを長年使用しており、確実に機能します。
クラスタ環境では、ブラウザにログインページが表示され、有効なユーザー名とパスワードを入力して送信ボタンをクリックすると、j_security_checkによって応答ヘッダーの場所ページがウェルカムファイルではなくログインページとして設定されます。ちょうど今行っていたログインページに進みます。
MySQLの一般的なクエリログを有効にしましたが、パスワードとグループ名が適切なユーザーの適切なテーブルから読み取られていることがわかります。
javax.enterprise.system.core.security.level = FINESTを設定しようとしましたが、サーバーログに出力がありません。
同じアプリをクラスターではなくローカルサーバーにデプロイすると、localhost：8080/にアクセスしてログインできます。「localhost」と入力してロードバランサーを実行すると、機能しません。
j_security_checkは認証をトリガーしたページ（おそらくここで何が起こっているのか）に転送できることを知っていますが、「認証をトリガーしたページ」がない場合、いつウェルカムファイルに転送しますか？編集：今わかりましたが、常にリファラーにリダイレクトされます。この場合はコンテキストルートです。コンテナには、実際に表示されるページを決定するいくつかのルールが必要です。私のクラスターの例では、web.xmlのwelcomeファイルではありません。
また、クラスター構成で認証レルムを設定します。
asadmin> create-auth-realm --target c1 --classname com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm --property jaas-context=jdbcRealm:datasource-jndi=jdbc/sportquest:user-table=users:user-name-column=username:password-column=password:group-table=users:group-name-column=groupname:digest-algorithm=SHA-256:encoding=Base64
2つの環境で考えられる唯一の違いは、クラスターのセットアップに、http-> https（httpd.conf）から先に進むmod_rewriteルールがあることです。
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# This redirects from thingy.com to www.thingy.com
#
RewriteCond %{HTTP_HOST} !^thingy\.com$ [NC]
RewriteRule ^(.*)$ %{HTTPS}://thingy.com/$1 [R=301,L]
編集：Chrome開発ツールのネットワークトレースの下に追加
/ MyAppとしてデプロイされた作業シナリオ：
GET http://localhost:8080/MyApp - 301 Moved Permanently (from cache)
GET http://localhost:8080/MyApp/ - 200 Ok
... login page loads ...
POST http://localhost:8080/MyApp/j_security_check - 302 Moved Temporarily
the form data contains user/pass as expected & response header Location:
http://localhost:8080/MyApp/
GET http://localhost:8080/MyApp/ - 200 Ok
... welcome-file page loads ...
ルートとしてデプロイされた動作しないシナリオ（クラスター）/：
GET http://localhost/ - 301 Moved Permanently (from cache)
GET https://localhost/ - 200 Ok
... login page loads ...
POST https://localhost/j_security_check - 302 Moved Temporarily
the form data contains user/pass as expected & response header Location:
https://localhost/
GET https://localhost/ - 200 Ok
... the login page loads ...
無効なログイン資格情報を入力すると、どちらの場合もフォームエラーページに正常にリダイレクトされます。
誰か提案がありますか？私はそれを見ていません。ありがとう。
ps私はブラウザのキャッシュをきれいに試しましたが、助けにはなりません！
更新：問題は、clustered / mod_jk環境で、j_security_checkからのポストバックに新しいセッションIDを持つSet-Cookieがあるため、次のリクエストが別のセッションで着信することです。これはスティッキーセッションと関係があるようですが、それを修正する方法がまだわかりません。ロードバランサーのsticky_sessionsをtrueとfalseに設定しようとしましたが、どちらも役に立ちません。
jvmRouteは、両方のインスタンスに対してワーカーに設定されます。