UserNamePasswordValidator

UserNamePasswordValidator

本文介绍了UserNamePasswordValidator:当DI和框架冲突时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在为一个WCF服务构建一个自定义的UserNamePasswordValidator。我正在使用Autofac + WCF / multitenant进行配置,所有这些都整齐地配合在一起。然而,我不知道用什么策略来接线/实施这个验证类。

I am building a custom UserNamePasswordValidator for a WCF service. I am wiring up the service with Autofac + WCF/multitenant, all fitting neatly together. However I'm not sure what strategy to use to wire/implement this authentication class.

理想情况下,我将从

public class MyValidator : UserNamePasswordValidator {
    public MyValidator(Func<Owned<IMyUserService>> userservicefactory) {
        ...
    }
}

但是,由于使用了UserNamePasswordValidator的方式,这并不是完全可能的通过WCF(唯一的选项似乎是无参数的构造函数)。

However, this isn't strictly possible because of the way that a UserNamePasswordValidator is consumed by WCF (the only option appears to be parameterless constructor).

所以,问题:


  1. 我是正确还是有一些WCF配置voodoo可以配置UserNamePasswordValidator 工厂

  2. 如果否,最多在这种情况下可以使用DI-correct回退策略?


推荐答案

服务主机在启动时或在自定义ServiceHostFactory中的代码。

I configured the service host in code at startup or within a custom ServiceHostFactory.

从XML配置中,我删除了

From the XML configuration, I removed

<userNameAuthentication
          userNamePasswordValidationMode="Custom"
          customUserNamePasswordValidatorType="Common.MyCustomUsernamePasswordValidator, Common"/ -->

由于我在托管之前配置了我的容器:

And since I configured my container prior to hosting:

var auth = host.Credentials.UserNameAuthentication;
auth.UserNamePasswordValidationMode = UserNamePasswordValidationMode.Custom;
auth.CustomUserNamePasswordValidator = container.Resolve<Common.MyCustomUsernamePasswordValidator>();

这篇关于UserNamePasswordValidator:当DI和框架冲突时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-15 13:08