3

カスタムの USERNAME-PASSWORD バリデーターを使用して、WCF サービスを開発しています。

UserNamePasswordValidatorから継承するCustomUserNameValidatorがあります。

IAuthorizationPolicyから継承するCustomAuthorizationPolicyも使用します。

カスタム承認ポリシーのEvaluateメソッドは次のようになります。

    // this method gets called after the authentication stage
    public bool Evaluate(EvaluationContext evaluationContext, ref object state)
    {
        // get the authenticated client identity
        IIdentity client = GetClientIdentity(evaluationContext);

        // set the custom principal
        evaluationContext.Properties["Principal"] = new CustomPrincipal(client);

        return true;
    }

ご覧のとおり、 Evaluateを呼び出すたびに新しいCustomPrincipalオブジェクトを作成します(これは、サービスで呼び出されるすべての操作で行われます)。

これは私のCustomPrincipalコンストラクターがどのように見えるかです:

    public CustomPrincipal(IIdentity identity)
    {
        IdentityObject = identity;
        GetUser(IdentityObject.Name);
        EnsureRoles();
    }

GetUserメソッドとEnsureRolesメソッドは、SQL データベースにアクセスして、ユーザーのロールを確認します。

私の質問は-なぜこれがすべての操作で発生する必要があるのですか??

クライアントがサービスに初めて接続するときだけでなく、すべての操作でCustomPrincipalの作成が行われるのはなぜですか?

サービスで呼び出されるすべての操作について、 「CustomPrincipal」がデータベースにアクセスし、ユーザーとそのすべてのロールを再取得する理由がわかりません...

[更新] これは、クエリ サービス インターフェイスの外観です。

[ServiceContract(Namespace = "http://www.my1fj.com/QueryService/2012/", SessionMode = SessionMode.Required, ProtectionLevel = ProtectionLevel.EncryptAndSign)]
public interface IQueryService
{
     // Some operations
}
4

1 に答える 1

1

あなたのサービスが呼び出しごとのサービスであり、呼び出しごとのサービスではすべての呼び出しで認証チェックが行われることを願っていますが、セッションごとのサービスの場合、チェックはセッションの開始時にのみ行われます (セキュリティ ネゴシエーションがオンになっている場合)。

..ここから

毎回データベースにアクセスする代わりに、それらをサービスにキャッシュできます。

アップデート：

サービスは、コールごと/セッションごと/シングルトンであり、サービス クラスに適用されるのInstanceContextModeプロパティによって決定されます。ServiceBehavior

元。

[ServiceContract]
interface IMyContract {...}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)] 
class MyService : IMyContract {...}

詳細については、この投稿を確認してください。InstanceContextModeプロパティの詳細については、これを確認してください。

于 2012-06-18T13:06:56.497 に答える