問題タブ [httpsession]

サーブレット HttpSession はどこに保存されますか?

機密情報を HttpSession 属性に保存しても安全ですか。

ユーザーが悪意を持ってセッション属性を変更できますか?

アプリケーション バックグラウンド セキュリティ: アプリケーションはすべて、プライベート エクストラネット (および/またはローカル イントラネット - インストール インスタンスに応じて) でホストされます。したがって、セキュリティは重要ですが、イントラネット上のアプリケーションほど重要ではありません。ただし、システムが簡単にハッキングまたはハイジャックされないことが重要であると述べています。

アプリ: アプリケーションは 2 つの部分に分かれています:-

• クラス ライブラリ (dll)
• 認証 フロントエンド ASP.NET アプリケーション

dll はフロントエンド認証アプリケーションの一部であり、ユーザーの認証を必要とする他のアプリケーション (「コンシューマー アプリ」) に追加されます。

認証アプリは、すべてのユーザー、ユーザーがアクセスできるアプリケーション、およびユーザー名に基づくアクセス許可レベルの中央ストアです。

dll がインストールされているコンシューマー アプリの場合、エンド ユーザーがログインを要求するページにアクセスすると、コンシューマー アプリは認証アプリケーションの login.aspx ページを appid と共に起動します。彼らは必要な権限を持っており、認証アプリはそれらを消費者アプリに送り返します（暗号化されたデータを含むフォームを介して）-これには、ユーザーが誰であるか、ユーザー名、実名、職務、組織などに関する基本データが含まれます...そして重要なことにコンシューマー アプリのアクセス許可レベルのリスト。

次に、コンシューマー アプリはそのデータを取得し、処理、復号化などを行い、フォーム認証 Cookie を作成し、ユーザー クラスとユーザー ロール クラスを設定します。これはすべて dll 自体から行われます。

問題

これですべてうまくいき、最初はすべてのデータが認証 Cookie のユーザーデータ部分に保存されていましたが、ここに問題があります....

コンシューマー アプリ (社内で作成された中心的なアプリが 1 つあります。1 人のユーザー (主にアプリケーション管理者) に関連付けられた多くのアクセス許可 (ユーザー ロール) を持つことができるため、大量のデータを保持できるものが必要です。認証 Cookie が保持できる 4KB を超えています。

したがって、これをセッション変数に入れようとしました。最初は、復号化されたデータをすべて「userdata」と呼ばれる単一のセッション変数に送信した単一の変数です。次に、リクエストが行われたときに確認します。

でも...

私が抱えていた最初の問題は、認証 Cookie の寿命がセッションよりも長いように見えることでした。セッションを 35 分 (AuthCookie より 5 分長い) に延長することでこれを修正したと思います。

しかし、コンシューマー アプリ プログラマーがコードを変更し (Visual Studio 2010 を介してデバッグで localhost を実行)、ブラウザーを更新すると、AuthCookie は残りますが、セッションは消えます。最初は、デフォルトの InProc セッション モードを使用していますが、これが問題になる可能性があります。

私の仮定は正しいですか？セッションと AuthCookie をプログラムで同期する方法はありますか?

この問題を解決するための他のアドバイスはありますか?

私は少し混乱しています。

正しく動作する SSL (https:8443) を使用して Liferay/Tomcat 7 サーバーを構成しました。

https://192.168.4.44または 215.44.24.67のように、IP でサーバーを呼び出すと、すべて正常に動作します。(これらは単なるサンプルです...) 私のウェブブラウザでは正しく開きます。

しかし、ブラウザーで dns を使用してサーバーを開いてサーバーにアクセスしようとすると、https://myname.mycompany.comのように、ブラウザーはセッションも Cookie も取得しません。ブラウザで Cookie を無効にすると、無限ループが発生します。

このため、jsf ポートレットの画像が読み込まれません。ページを更新すると、すべてが読み込まれ、最終的にセッションが開始されます。

SSL を使用するために、iptables にいくつかのエントリを作成しました。

私を助けてくれるTomcatの専門家はいますか?

オーストリアからのご挨拶

ヨハン

Java Servlet API で を取得する唯一の方法は、 ( JavadocServletContext )のインスタンスを使用することです。HttpSession

セッションを作成せず、サーブレット コンテキストのみが必要な場合はどうすればよいですか? つまり、クラスgetServletContext()にメソッドがないのはなぜですか。HttpServletRequest

編集

ServletContext初期化中にサーブレットを受け取るので、サーブレット自体から取得できることはわかっています。HttpServletRequestただし、サーブレットにリンクされていても、単独では取得できません。では、リクエストがあってもサーブレットへの参照がない場合はどうなるでしょうか?

HttpSessionCookie と URL 書き換えの上に構築された高レベルのインターフェイスです。つまり、セッション ID のみがクライアント側に保存され、それに関連付けられたデータがサーバー側に保存されます。

HttpSessionサーバー側で実際にデータはどこに保存されますか? JVMメモリまたは他の場所で？メモリ内データベースに保存するなど、保存場所を変更できますか?

データベースにない場合、多数のクライアントが同時に同じセッション データで作業する場合、同時実行性の問題はありますか?

前の質問に続きますが、アプリケーションのセッションが最初に開始されたときに、セッション スコープの JSF Bean を初期化しようとしています。そのため、Web アプリケーションで最初にアクセスしたページに関係なく、ユーザーは Bean を使用できます。私のカスタムリスナー:

ただし、これによりスタック オーバーフロー エラーが発生します。put()クラスのメソッドがSessionMap新しい を作成しようとしているように見えるHttpSessionため、リスナーで無限ループが発生します。アプリケーションのセッションが最初に開始されたときに、この問題に遭遇することなく JSF セッション スコープ Bean を初期化するにはどうすればよいですか?

WebSphere 7で実行されているSpring 3でJSF 2を使用しています。

ありがとう！

人々が共同作業できるようにする Web アプリケーションを作成しています。サービスの一部を、個々の http セッションではなく、コラボレーション (数人が関与する) に限定したいと考えています。Scope豆を保存するカスタムを作成しました。Bean のライフサイクルを管理するために、次のように関連付けられたセッション ID を追跡します。

セッションが終了したら、特定の Bean 名に関連付けられたアクティブなセッションのリストからセッション ID を削除したいと考えています。セットが空になったら片付けます。

管理セッションの終了を考える最も簡単な方法は を使用することですがHttpSessionListener、私Scopeとリスナーの間に切断があります。次の可能性が見えます。

1. を静的に作成しHttpSessionListener、単一のインスタンスを想定して、サブスクリプション リストを管理し、Scopeインスタンスにそのイベントをサブスクライブさせることができます。しかし、それは冗長に思えます。私はこれに対するシングルトン パターンが好きではありません。

2. HttpSessionのにアクセスできる場合は、セッションに保存されているリストScopeに を追加し、Scopeそのリストのメンバーにセッションが終了することをリスナーに通知させることができます。Scopeしかし、インスタンス内のセッション オブジェクト (ID だけでなく) を取得する方法がわかりません。

3. Scopeインターフェイスを実装してその状態を直接更新することはできHttpSessionListenerますが、リスナーをプログラムで登録する方法がわかりません。それを行う公的な方法はありますか？

4. より良い方法はありますか？

ご協力いただきありがとうございます、

遺伝子

私はJSPクラスを受講しましたが、使用する前にHttpSessionのすべての属性を常に削除する必要があることを学びました。そこで、クラスメートの1人が、「使用を終えた後、HttpSessionを完全に削除するのはどうですか？」と尋ねました。

だから、私の質問は「HttpSessionを削除できますか？」です。

これまでのところ、私が理解していることから... HttpSessionは、HttpServletRequestやHttpServletResponseと同じように、サーブレットコンテナによって作成されます。HttpServletRequestを介して取得しますが、手動で削除することはできません。代わりに、セッションを終了するように設定できるタイムアウトがあります。削除できないため、使用する前に必ずセッションをクリーンアップする必要があります。私は正しいですか？

ありがとう！

問題：

ASP.NET サイトでセッションを使用すると、複数の要求をほぼ同時にロードすると、劇的な遅延 (500 ミリ秒の倍数) が発生します。

より具体的には、私の問題

私たちのウェブサイトは、SessionId のみにセッションを使用します。このキーを使用して、ユーザー情報などを含む db テーブルを検索します。これは最小限のセッション データを格納するため、適切な設計のように思われました。残念ながら、セッションに何も保存しないと SessionId が変更されるため、Session["KeepId"] = 1;. これは、SessionId が変更されないようにするのに十分です。

一見関係のないことですが、このサイトはコントローラー アクションを通じてカスタマイズされた製品画像を提供します。このアクションは、必要に応じて画像を生成し、キャッシュされた画像にリダイレクトします。これは、1 つの Web ページに画像やその他のリソースが含まれ、ASP.NET パイプラインを介して数十の要求が送信されることを意味します。

何らかの理由で、(a) 同時に複数のリクエストを送信し、(b) なんらかの方法でセッションが関与している場合、約 1/2 の時間でランダムな 500 ミリ秒の遅延が発生します。場合によっては、これらの遅延は 1000 ミリ秒以上になり、常に最大 500 ミリ秒の間隔で増加します。リクエストが多いほど、待ち時間が長くなります。数十の画像を含むページでは、画像によっては 10 秒以上待機することがあります。

問題の再現方法:

1. 空の ASP.NET MVC Web アプリケーションを作成する

2. 空のコントローラー アクションを作成します。

   /li>

3. そのアクションにヒットするいくつかの img タグを含む test.html ページを作成します。

   /li>

4. ページを実行して、firebug で高速な読み込み時間を確認します。

   

5. 次のいずれかを実行します (どちらも同じ結果になります)。

   • 空の Session_Start ハンドラーを Global.asax.cs に追加します。

     /li>

   • 何かをセッションに入れる

     /li>

6. ページを再度実行すると、応答がときどき/ランダムに遅延することに注意してください。

   

私がこれまでに知っていること

• MVC 2 & 3 および WebForms で発生します。
• どのブラウザでも発生します（FF、Chrome、IE、Safariを試しました）
• デバッガーが接続されているかどうかに関係なく発生します。また、実際にセッションに保存する必要はありません (上記の Session_Start の例を参照してください)。
• WebDev.exe、IIS Express、および IIS で発生します

私の質問

セッションを使用してこれらの遅延を回避するにはどうすればよいですか? 誰も修正を知っていますか？

修正がない場合は、セッションをバイパスして Cookie を直接使用する必要があると思います (セッションは Cookie を使用します)。

spring を使用して Web アプリケーションを開発しています。

ここに問題があります。これらの 3 つの URL があるとします。

www.sample.com/login.do

www.sample.com/homePage.do

www.sample.com/about.jsp

私がやりたいことは、ユーザーがログインしているかどうかにかかわらず、about.jsp ページにアクセスできるようにすることです。また、ユーザーがログインせずに homePage.do にアクセスしようとすると、login.do ページにリダイレクトされ、その逆も同様です。

これが機能するにはHTTPSessionが必要だと思いますが、SpringでHTTPSessionを管理する方法がわかりません。

いくつかのフィルターを使用してこれを達成できますか? もしそうなら、それを通して私を案内してもらえますか？

Spring MVC および/または Spring Annotations を使用したいと考えています。