asp.net 3tire アーキテクチャ(Farmer System web)を使用してプロジェクトを作成しました。そのプロジェクトの第 2 部として、Asp.net MVC4 (ポータル Web) を使用して別の Web サイトを開発しました。これらのプロジェクトは個別にホストされます。ユーザーが農家システムにログインすると、ポータルも使用できます。
ユーザーがポータルに移動するときに、ログ セッションを渡したい。どうすればいいのか誰か教えてください。
asp.net 3tire アーキテクチャ(Farmer System web)を使用してプロジェクトを作成しました。そのプロジェクトの第 2 部として、Asp.net MVC4 (ポータル Web) を使用して別の Web サイトを開発しました。これらのプロジェクトは個別にホストされます。ユーザーが農家システムにログインすると、ポータルも使用できます。
ユーザーがポータルに移動するときに、ログ セッションを渡したい。どうすればいいのか誰か教えてください。
ServiceStack ISession の使用
ServiceStack には、同じ Cookie ID を共有する MVC コントローラー、ASP.NET ベース ページ、および ServiceStack の Web サービス間で同じものを共有できる新しいISession
インターフェイスがあり、これらの Web フレームワーク間でデータを自由に共有できます。ICacheClient
ISession
注: ISession は、ServiceStack の MVC PowerPackで説明され、Sessions wiki ページで詳細に説明されているように、ServiceStack独自のコンポーネントを使用して既存の ASP.NET セッションを完全にバイパスするクリーンな実装です。
ServiceStack のセッション (キャッシュと JSON シリアライザー) を簡単に利用するには、コントローラーをServiceStackController (MVC の場合) またはPageBase (ASP.NET の場合) から継承します。
ウィキで読むことができる ServiceStack に追加された新しい認証/検証機能もあります。
ASP.NET セッションの使用
基本的にServiceStackは、ASP.NET または HttpListener ホストのいずれかで実行される軽量の IHttpHandler のセットです。IIS/ASP.NET (最も一般的) でホストされている場合、通常の ASP.NET 要求のように機能します。
ServiceStack では、基になる ASP.NET アプリケーションで構成されたキャッシュ プロバイダーとセッション プロバイダーにアクセスしたり、影響を与えたりするものはありません。有効にしたい場合は、ASP.NET (つまり、ServiceStack の外部) で通常どおりに構成する必要があります。以下を参照してください。
http://msdn.microsoft.com/en-us/library/ms178581.aspx
構成が完了すると、シングルトンを介して ServiceStack Web サービス内の ASP.NET セッションにアクセスできます。
HttpContext.Current.Session
または、基礎となる ASP.NET HttpRequest を介して次のように指定します。
var req = (HttpRequest)base.RequestContext.Get<IHttpRequest>().OriginalRequest;
var session = req.RequestContext.HttpContext.Session;
XML 構成への依存が必須であり、デフォルトでパフォーマンスが低下するため、私は ASP.NET のセッションの使用を避け、代わりにServiceStack に含まれるよりクリーンなキャッシュ クライアントを使用することを選択します。
基本的に、セッション (ASP.NET を含む) が機能する方法は、ブラウザー セッションを一意に識別する応答に追加される一意の IDを含む Cookieです。このIDは、ブラウザのセッションを表すサーバー上の一致するディクショナリ/コレクションを指します。
リンク先のIRequiresSessionインターフェイスは、デフォルトでは何もしません。これは、このリクエストを認証する必要があることをカスタム リクエスト フィルタまたはベース Web サービスに通知する方法です (つまり、検証/認証ロジックを配置する必要がある 2 つの場所)。 ServiceStack で)。
以下は、Web サービスがセキュアであるかどうかを確認し、セキュアである場合は認証済みであることを確認するBasic Auth の実装です。
[Authenticate]属性でマークされたすべてのサービスを代わりに検証する別の認証実装と、リクエスト DTO に属性を追加してサービスの認証を有効にする方法を次に示します。
上記の実装は、次のバージョンの ServiceStack に含まれるマルチ認証プロバイダー モデルの一部です。アプリケーションで新しい Auth モデルを登録して構成する方法を示す参照例を次に示します。
新しい Auth モデルは完全にオプトインの便利な機能です。単純にそれを使用することはできず、リクエスト フィルターを使用して、または基本クラスで ( OnBeforeExecuteをオーバーライドすることにより) 同様の動作を自分で実装することはできません。実際、新しい Auth サービスは実際には ServiceStack 自体に組み込まれているわけではありません。実装全体は、オプションのServiceStack.ServiceInterfaces プロジェクトにあり、カスタム リクエスト フィルターを使用して実装されます。
私が長年使用してきたさまざまな認証戦略を次に示します。
[Attribute]で認証が必要なサービスをマークします。おそらく最も慣用的な C# の方法であり、セッション IDが Cookie を介して渡される場合に理想的です。
特に Web コンテキストの外部では、より明示的なIRequiresAuthenticationインターフェイスを使用する方がよい場合があります。これは、認証に必要な User および SessionId への厳密に型指定されたアクセスを提供するためです。
アドホック ベースで、それを必要とする各サービスで認証するための 1 ライナーを持つことができます。認証を必要とするサービスがほとんどない場合に適したアプローチです。