3

小さなものから始めたWebアプリケーションがあり、追加された新機能はすべて同じプロジェクトの一部として作成されましたが、これらのアドオン用の新しいプロジェクトを作成したいと思います...

新しいプロジェクトを作成し、メイン プロジェクトの global.asax を継承し、メイン プロジェクトの web.config にも問題なくアクセスしますが、グローバル asax コードでは、データの整合性をチェックするセッションがあり、ユーザーがログインしています..ここで問題が発生しています..ユーザーはログインしていますが、メインプロジェクトによって設定されたセッションユーザー ID にアドオンプロジェクトがアクセスできないため、ユーザーがログインしていないことを示すサイトエラーが発生します。

現在、セッション状態サーバーまたは SQL 状態サーバーを使用していません。一部の古いコードの頭痛の種を避けるために、使用を避けたいと考えています。

また、ミューテックスのルートに行きたくありません..可能であれば、Windowsコーディングからも離れたいです...

セッションで何が起こるかのサイトの概要: ユーザーが asp コード (.net 1.1 コード) でログイン ユーザーが認証され、正常にログインし、そのユーザーの GUID をデータベースに送信し、メイン プロジェクト (.net 2.0 コード) がそれを取得しますguid は、ユーザー データを取得し、ユーザー ID をセッションに保存します。ユーザーが誰であるかを知る必要があるページは、セッションから取得します("userid")

そのため、global.asax を継承する別のプロジェクトを作成し、web.config にアクセスできます - 完了!

これに加えてやりたいこと: この新しいプロジェクトにページ (メイン プロジェクトのアドオン機能) を含め、このページにメイン プロジェクトから設定されたセッション ("userid") にアクセスさせます。- これを行う方法がわからない...

4

6 に答える 6

3

複雑さを最小限に抑える最善の方法は、状態サーバーを使用することです。これは、彼らが解決するように設計された問題です。

そう言われて...

2 つのアプリケーションは (異なるランタイム バージョンであるため) 異なるプロセスで実行する必要があるため、データを直接共有することはできません。

1 つのオプションは、Web サービスまたはRemotingを使用することです。セッションのすべてのデータを格納する CustomSession オブジェクトを作成し、それぞれをGuidで識別することができます。Guid-CustomSession によってアプリケーション A で作成されたすべての既存のセッションを追跡し、クエリ文字列を介してアプリケーション B に Guid を渡すことができます。 . 逆に同じことを行うこともできます。

ここでの唯一の問題は、アプリ A のページからアプリ B のページに移動するとき、またはその逆の場合に、常に URL に Guid が提供されていることを確認する必要があることです。アプリケーションは、セッションが存在しないかどうかを常に確認し、Guid を使用して他のアプリにセッションがあるかどうかを確認できます。

一部の .NET データ構造 (多数ではない) は、.NET 1.1 と 2.0 の間で異なる方法でシリアル化されることに注意してください。そのため、リモート処理または Web サービスを介してオブジェクトを共有する場合は、そのことを考慮する必要がある場合があります。

于 2009-03-06T00:42:27.780 に答える
2

Web サービスまたはリモーティングの使用は、自分で実装する必要があることを除いて、Session State Server と似ています。

これを自分で行う場合は、前述していない問題がもう 1 つあります: セッション タイムアウトです。2 つのプロセスの両方が、セッションが最後に使用されたときについて同じ考えを持っていることを確認する必要があります。正しく行わないと (私はこれに遭遇しました)、アプリケーションの一部にログインしているように見えて、他の部分にはログインしていないように見える状態になるリスクがあります。

于 2009-03-06T05:17:23.360 に答える
2

セッションステートサーバーから離れたいと言ったのは知っています....

しかし、それでも私はそれが最良の選択肢だと思います。特に、将来のスケーラビリティと保守性のために、ログイン ID 以外のデータを共有する予定がある場合。また、ログイン データの共有は、クエリ文字列などを通じてクライアント側で保持するよりも、セッション状態サーバーを通じてより安全です。

しかし、繰り返しますが、セッション データを共有するために最終的に何をするにしても、他のポスター「Rex M」が指摘したように、共有するセッション データの種類とシリアライズ可能である必要があることに注意する必要があります。

于 2009-03-06T01:02:42.990 に答える
0

Rex M: 私たちは、同じバージョンの .net 間でセッション データを共有しようとしています。どちらも .net 3.5 を実行しており (.net 2.0 フレームワークで実行)、ログイン データを 2.0 フレームワークに xfer するコードが既にあります。

メイン プロジェクトは動作していますが、モジュールを追加したいと考えています。簡単に言えば、別の .net Web アプリケーションを追加する場合、名前空間を使用せず、セッション状態サーバーをセットアップし、参照をセットアップしてから、コンパイルすると、すべてがグレービーになります..

両方のアプリケーション (セッション データを共有しようとしていたアプリケーション) は 2.0 フレームワークを実行しており、両方とも同じアプリケーション プール内で、両方とも同じマシン キーと状態サーバー情報を使用しており、両方とも同じマシン上で異なるフォルダーから実行されています。 （ただし、同じ親フォルダーを共有しています）

これを機能させるためにできることはありますか？

(SQL 状態サーバーを使用せずに)。

于 2009-03-09T13:32:21.740 に答える
0

Cookie を使用してユーザー ID を保存できます。1.1 と 2.0 の両方のアプリケーションが問題なくアクセスできます。

于 2009-03-06T01:12:00.923 に答える
0

2 つの Web アプリケーション間を移動するときに、1 つ以上の暗号化されたクエリ文字列変数を使用して渡すことができます。これにより、2 つの Web アプリケーションで重要なセッション変数を照会して再確立できます。これが最も簡単な方法です。

于 2009-06-15T15:29:43.680 に答える