2012-04-30 9 views
0

ユーザーがどのアプリケーションにいるかにかかわらず、それぞれのweb.xmlの "sesion timeout"パラメータに基づいてユーザーをタイムアウトさせます。なぜアプリケーションが別々のWARにあるのか尋ねないでください。アーキテクチャはそうです。ユーザーはWebApp Aを介してログインし、WebApp Bにリダイレクトされます。ユーザーは別のWebアプリケーションにジャンプし続けることができます。 WebAppBなどには、数多くのAjaxコールがあります(私もそこに行くつもりはありません)。質問は、私がWebApp AとWebApp Bの間でセッションデータを共有できないという事実(私はここで間違っているかもしれません - これが私が助けを必要とする場所です)に陥るので、私は何も持っていません最初の要求がWebAppBとセッションタイムアウト「の後に」最初の要求に当たったとき、それは両方のケースではnullを返しますので、WebAppBでセッションタイムアウトと、複数のWebアプリケーション

httpServletRequest.getSession(false) 

をチェックすることで知る方法。私はWebAppAのセッションに「何か」を残し、WebAppBのセッションでその存在を確認する必要があります。これにより、Webアプリケーション内でセッション・データを共有する問題に戻ります。 DBストレージを使用することはできません。これは、すべてのリクエストでDBコールが行われることを意味します。 Tomcatの "crossContext"は、このようなシナリオで役立ちますが、このようなものはGlassfish(私が最近見つけたsun-web-app.xmlの "crossContextAllowed"プロパティがあります)に役立ちます。

私はかなりの時間これに取り組んできましたが、これはあなたの時間の価値ある質問でもありません - だから助けてくれたことに感謝します。

Trishul

答えて

1

私はGlassfishの実装のお手伝いをしますが、何が必要なのはWebアプリケーション間のシングルサインオンの形であることはできません。あなたは通常、2つのことを行う必要があるSSOは、このフォームを実装するには

:すべてのWebアプリケーションは、WebアプリケーションA、すなわち、共通のルートコンテキストを共有していることを確認してください

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

サーブレット/ JavaEEコンテナは、通常、必要なものを直接実装するSSO Realms/SessionManagersまたは同等のサンプルを提供するか、必要に応じて微調整することができます。

+0

返信いただきありがとうございます。私はさらに2時間待って、誰かが返事をするかどうかを見ます。さもなければ私はあなたのことを正しいものとしてマークします。再度、感謝します。 – trishulpani

関連する問題