ServiceStackISessionの使用
ServiceStackには、 MVCコントローラー、ASP.NETベースページ、および同じCookie IDを共有するServiceStackのWebサービス間で同じものを共有できる新しいISession
インターフェイスがあり、これらのWebフレームワーク間でデータを自由に共有できます。ICacheClient
ISession
注:ISessionは、ServiceStackのMVC PowerPackで説明され、Sessions wikiページで詳細に説明されているように、ServiceStack独自のコンポーネントで既存のASP.NETセッションを完全にバイパスするクリーンな実装です。
ServiceStackのセッション(キャッシュとJSONシリアライザー)を簡単に利用するには、コントローラーをServiceStackController(MVCの場合)またはPageBase(ASP.NETの場合)から継承します。
ServiceStackには、新しい認証/検証機能も追加されています。これについては、wikiで読むことができます。
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
構成が完了すると、シングルトンを介してServiceStackWebサービス内のASP.NETセッションにアクセスできます。
HttpContext.Current.Session
または、基盤となるASP.NETHttpRequestを介して次のコマンドを実行します。
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サービスが安全であるかどうかを確認し、安全である場合は認証されていることを確認する基本認証の実装です。
代わりに、 [Authenticate]属性でマークされたすべてのサービスを検証する別の認証実装と、リクエストDTOに属性を追加してサービスの認証を有効にする方法を次に示します。
ServiceStackの新しい認証モデル
上記の実装は、ServiceStackの次のバージョンに含まれるマルチ認証プロバイダーモデルの一部です。これは、アプリケーションで新しいAuthモデルを登録および構成する方法を示す参照例です。
認証戦略
新しいAuthモデルは、完全にオプトインの便利な機能です。これは、リクエストフィルターを使用して、または基本クラスで( OnBeforeExecuteをオーバーライドすることにより)自分で使用したり、同様の動作を実装したりすることができないためです。実際、新しいAuthサービスは実際にはServiceStack自体に組み込まれていません。実装全体は、オプションのServiceStack.ServiceInterfacesプロジェクトに存在し、カスタムリクエストフィルターを使用して実装されます。
これが私が何年にもわたって使用したさまざまな認証戦略です:
認証が必要なサービスを[属性]でマークします。おそらく最も慣用的なC#の方法であり、セッションIDがCookieを介して渡される場合に理想的です。
特にWebコンテキストの外部では、認証に必要なユーザーとSessionIdへの強い型のアクセスを提供するため、より明示的なIRequiresAuthenticationインターフェイスを使用する方がよい場合があります。
アドホックベースで、それを必要とする各サービスで認証するための1ライナーを持つことができます。認証を必要とするサービスが非常に少ない場合に適したアプローチ。