3

https://sub.domain.com/login.cfmに1つのログインフォームを持つドメインsub.domain.comがあるとします。

ルートディレクトリには、を使用してアプリケーションに名前を付けるApplication.cfcがありますTHIS.Name = "MyApp";。

このWebサイトには、ルートApplication.cfcを拡張する独自のApplication.cfcを使用して、個別のアプリケーションとして実行したいサブディレクトリがいくつかありますが、それぞれに独自の名前があるため、一意のアプリケーションスコープ変数を作成できます。そのアプリケーションに：

例：sub.domain.com/site1/Application.cfc

sub.domain.com/Application.cfcを拡張します（プロキシcfcを使用） THIS.Name = "MyApp_Site1";

アプリケーションに固有のアプリケーションスコープ変数を設定します。

ただし、https：//sub.domain.com/login.cfmにログインすると、そこに設定されているSESSIONスコープ変数はすべてアプリケーション名「MyApp」に関連付けられます。

ルートディレクトリApplicationで有効なログインを受け入れ、ユーザー固有のプロパティを引き継いでユーザーをアプリケーションに転送するには、どのようなソリューションを使用できますか？

4

3 に答える 3

4

@Dave Fergusonが述べたように、セッションデータを共有する最も簡単な、最も冷静な方法は、それを単一のアプリケーションとして保持することです。名前が同じである限り、コンテンツを別のフォルダーに置くこともできます。

探しているものを取得するために、FW \ 1などのフレームワークを使用する必要はありませんが、少し簡単になる場合があります。キーはサブアプリケーション名で、いつでもアプリケーションスコープ内に構造体を格納できます。たとえば、application.myvariableはapplication[request.subappname].myvariableになります。これにより、1つのアプリケーションを使用できますが、アプリケーション変数のスコープはさまざまなサブアプリケーションになります。セッション変数でも同じことができます。

@Brianが述べたように、別のアプローチでは仲介ストアを使用します。その後、任意のキーを使用してセッションデータを保存できます。@Dave Fergusonが述べたように、CFIDとCFTOKENをドメインCookieとして設定します（特にCF10ではCookieの設定にいくつかの改善があります）。そうすれば、同じCFIDとCFTOKENがアプリケーション間で使用されます。それらはまだ異なるセッションを持っていますが、同じセッション識別子を使用します。次に、その組み合わせを中間ストアのデータのキーとして使用できます。

これを行うにはデータベースが従来の方法ですが、アプリによっては、同時実行性とロックの問題、シリアル化/逆シリアル化の問題、またはパフォーマンスが発生する可能性があり、古いデータや期限切れのデータのパージが常に処理されます。したがって、これを処理するためにehcacheやmemcachedのようなものを調べたいと思うかもしれません。

特にehcacheは魅力的なオプションです。ColdFusion9以降にバンドルされており、設定に応じてメモリとディスクの両方を使用でき、キャッシュ内のデータはサービスの再起動（または再起動）後も存続でき、次のように設定できます。一定量の非アクティブ状態が発生すると、レコードが自動的に期限切れになります。はい、カスタムキャッシュに使用できます。

このアプローチを取る場合は注意することをお勧めします。毎回（たとえばonRequestStartで）キャッシュからデータを取得する場合のパフォーマンスへの影響と、セッションがタイムアウトするまでonSessionStart（）でデータを取得し、多くのアプリケーション間で重複を保持することによるメモリ消費量を比較検討する必要があります。どのルートを使用するかは、アプリケーションのパフォーマンス特性、セッションデータのサイズなどに完全に依存します。

于 2012-08-01T00:39:14.990 に答える
3

簡単な答えは、できません。しかし、それも完全に真実ではないので、少し説明させてください。まず、セッションはアプリケーション名に関連付けられています。したがって、同じアプリケーション名を持つ 2 つの application.cfc ファイルがある場合、セッションは両方で使用できます。しかし、それはあなたがしていることではありません。それぞれに異なる名前があるため、それぞれに新しいアプリケーション スコープがあり、新しいセッションも同様です。

試してみたいことは、FW\1 とサブ アプリケーションを使用することです。これにより、単一のメイン app.cfc が得られますが、機能を個別のグループに分けることができます。

ログイン ページからドメイン レベルの Cookie を設定することもできます。その後、他のアプリケーションでそれらを使用して、やみくもにセッションを作成できます。

于 2012-07-31T23:55:29.207 に答える
1

ColdFusion のセッションは、特定のアプリケーションに関連付けられています。ColdFusion のセッション構造を使用してアプリケーション間でそれらを共有することはできません。(同じサーバー上の任意のアプリケーションからセッション情報を取得できるとしたら、共有ホストで発生するセキュリティ上の悪夢を想像してみてください。)

ユーザーがアプリのルートに正常にログインしたときに、セッション情報をデータベースまたはその他の永続化メカニズムに保存し、サイト固有のアプリケーションへの最初のリクエストで顧客のセッション情報をロードする必要があります。これは、サイト固有のアプリケーションの application.cfc の onSessionStart() または onRequestStart() で行うことができます。

于 2012-07-31T20:20:04.413 に答える