6

ColdFusion セッションと J2EE セッションに利点はありますか?

ColdFusion セッションのドキュメントでは、J2EE セッションの利点について言及されていますが、 ColdFusion セッションの利点については言及されていません。J2EE セッションは ColdFusion MX (2002 年にリリース) から利用可能になりましたが、標準の ColdFusion セッションを使用している人はまだたくさんいます。ColdFusion セッションにはない J2EE セッションの欠点はありますか?

J2EE セッション管理には、ColdFusion セッション管理よりも次の利点があります。

  • jsessionidJ2EE セッション管理では、各セッションの開始時に新たに作成されるセッション固有のセッション ID を使用します。
  • ColdFusion ページと、ColdFusion ページから呼び出す JSP ページまたは Java サーブレットの間でセッション変数を共有できます。
  • Session スコープはシリアライズ可能です (後で元のオブジェクトに完全に復元できる一連のバイトに変換できます)。ColdFusion セッション管理では、Session スコープはシリアル化できません。サーバー間で共有できるのは、シリアライズ可能なスコープのみです。

したがって、次のいずれかの場合は、J2EE セッション管理の使用を検討してください。

  • 特にクライアント変数も使用する場合は、セッションのセキュリティを最大限に高めたい
  • 1 つのアプリケーション内の ColdFusion ページと JSP ページまたはサーブレットの間でセッション変数を共有したい。
  • Client スコープで使用するためにクライアント識別 Cookie を維持しながら、セッションを手動で終了できるようにしたいと考えています。
  • クラスター化されたセッションをサポートしたい。たとえば、サーバー間のセッション フェイルオーバーをサポートする場合などです。
4

4 に答える 4

3

上記の質問で示したように、Java EE セッション Cookie を使用することには重大な欠点はなく、それらを使用することにはいくつかの利点があります。

Java EE トークンの 1 つの欠点は、Cookie をプログラムで簡単に変更できないことです。CFトークンは可能です。CF トークンを変更して、セッションのみにすることができます。SSL のみおよび httpOnly に変更することもできます。

Java EE トークンを SSL 専用および httpOnly にすることもできますが、これには JVM 引数が含まれます。

CF9 では、Adobe は CF トークンのランダム性も改善し、Java EE トークンと同等になりました。

どちらを使用するかは問題ではないと思います (CF9 以上を使用していると仮定します)。しかし、Java EE トークンは、すぐに使用できる安全な作業に最も近いものです。ただし、Cookie を「セッションのみ」に設定するだけでなく、SSL のみおよび httpOnly にしたい場合は、JVM 設定を掘り下げる必要があります。App.cfc でそれを行うことはできません。

于 2012-08-07T14:27:18.133 に答える
1

ColdFusion における J2EE セッション変数の主な欠点の 1 つは、それらを「安全な」Cookieにするなどの変更がインスタンス全体で行われることです。

これは、ColdFusion 管理者自身を含め、そのインスタンスで実行されているすべてのサイトが https で実行される必要があることを意味します。セッションを必要とする複数のサイトをホストするサーバーの場合、これは一般的に問題になります。さらに、ビルトイン Web サーバーから ColdFusion Administrator を実行している場合は、ssl で動作させるためのちょっとしたプロセスがあります。

J2EE Cookie の文書化された利点が必要であり、Cookie を安全にする必要がある場合は、セッションを必要とするすべてのサイトが https 上にある必要があります。

文書化されている J2EE Cookie の利点がまったく必要なく、CF9 以降を実行している場合は、ColdFusion Cookie を使用することをお勧めします。

Railo にも同じ問題がありますが、サイトごとにセッション Cookie を選択できる属性がcfapplicationタグにあるため、より柔軟性があります。sessiontypej2eecf

于 2012-09-08T22:24:11.797 に答える
1

CF ネイティブ セッションはセッション Cookie を使用しないため、ブラウザ/マシンの再起動後も継続できますが、すべての Java EE サーバーはデフォルトでセッション Cookie を使用するため、セッションはブラウザが開いている間のみ継続できます。

この動作がサーブレット JSR で指定されている場所を見つけることができませんが、サーブレット仕様 3.0 (つまり、JRun ではない) では、CF ネイティブ セッションの動作を模倣するために、Java EE セッション Cookie の有効期限を設定できます。

nosilleg が言及しているように、これはおまけになる可能性がありますが、作業中のアプリのセキュリティ要件によっては、セキュリティ上の問題と見なされる可能性もあります。

于 2012-08-07T12:28:14.463 に答える
0

リクエスト間でセッション変数が完全に失われるという小さな問題が 1 つあります。J2EE セッションで cfhttp 投稿を使用していました。次のシナリオを想像してください。 1. wwwRoot/test フォルダーの call.cfm が、同じフォルダー内のインデックス ページを呼び出します。2. index.cfm は要求を wwwRoot/test/controller/login.cfm に送信します。3. login.cfm は、いくつかのセッション変数を設定し、ユーザーを wwwRoot/test/index.cfm に送信します。 4. index.cfm は、作成されたセッション変数を認識しません。

すべての送信リクエストは、addtoken="yes" を指定した cflocation を介して行われます。

J2EE セッション変数をオフにして、ビオラ! それは、本来あるべき方法と同じように機能します。

cflocation とセッション変数

于 2014-06-13T13:03:29.203 に答える