0

現在のプロジェクトで奇妙な問題に直面しています。

Glassfish3.1サーバーに複数のSpringMVCベースのWebアプリをデプロイしました。どのアプリケーションであるかに関係なく、それぞれのweb.xmlの「セッションタイムアウト」パラメーターに基づいてユーザーを「タイムアウト」できる必要があります。ユーザーがオンになっています。アプリケーションが別々のWARにある理由を尋ねないでください-アーキテクチャはそうです。ユーザーはWebAppAを介してログインし、WebApp Bにリダイレクトされます。その後、ユーザーはさまざまなWebアプリにジャンプし続けることができます。WebAppBなどにも多数のAjax呼び出しがあります（私はそこに行くことすらありません）。質問は、WebAppAとWebAppBの間でセッションデータを共有できないという事実に要約されます（私はここで間違っている可能性があります-そしてこれは私が助けを必要としているところです）そして私は何も持っていませんチェックして知る方法 

httpServletRequest.getSession(false)

WebAppBでは、最初のリクエストがWebAppBにヒットした場合と、セッションタイムアウトの「後」の最初のリクエストの場合の両方でnullが返されるためです。WebAppAのセッションに「何か」を保持し、WebAppBのセッションにその存在を確認する必要があります。これにより、Webアプリケーション内でのセッションデータの共有の問題に戻ります。DBストレージを使用することはできません。これは、すべてのリクエストでDB呼び出しを行うことを意味するためです。Tomcatの「crossContext」がそのようなシナリオで役立つという方向性をグーグルで調べましたが、Glassfishではこのようなものが役立ちます（最近見つけたsun-web-app.xmlの「crossContextAllowed」プロパティがあります）。

私はかなり長い間これに悩まされてきました、そしてこれがあなたの時間の価値がある質問であるかどうかさえわかりません-それで助けてくれてありがとう。

トリシューラ

4

1 に答える 1

1

Glassfishの実装についてはお手伝いできませんが、必要なのはWebアプリ間のシングルサインオンの形式です。

この形式のSSOを実装するには、通常、次の2つのことを行う必要があります。

  1. すべてのウェブアプリが共通のルートコンテキストを共有していることを確認してください。つまり、ウェブアプリAは/ commonroot / webappAにあり、ウェブアプリBは/ commonroot/webappBにあります。これは、ユーザーが2つのWebアプリを切り替えるときに、同じセッションIDを2つのWebアプリに配信する必要があるためです。セッションIDは通常Cookieに保存され、ブラウザはパスに基づいてCookieを配信します。Glassfish（TomcatやJettyの場合と同様）には、WebアプリケーションAがパス "/ commonroot"（/ commonroot / webappAではなく）にCookieを配信するように「強制」し、webappBが同じことを行うように設定する必要があります。次に、webappAまたはwebappBにアクセスすると、/commonRootパスに関連付けられたCookieから一意のセッションIDが取得されて提供されます。
  2. 同じ「SSOコンテキスト」内のすべてのWebアプリがユーザーの共通セッションを共有したら、これらのWebアプリに共通の一意のストアからセッションにアクセスさせる必要があります。DBは通常の方法ですが、速度を求めている場合は、memcachedやhazelcastなどの方が適切な場合があります。DBを使用する利点は、セッションの永続性を追加で提供することです。セッションストアがバウンスされた場合、有効期限が切れていないセッションで呼び出しを行ったユーザーは、再度ログインしなくても透過的に再接続されます。

サーブレット/JavaEEコンテナは通常、SSOレルム/ SessionManagerまたは同等のサンプルを提供します。これらのサンプルは、必要なものを直接実装するか、ハッキングしてニーズに合わせて微調整できます。

于 2012-04-30T09:27:57.940 に答える