UserNamePasswordValidator：当DI和框架冲突时 [英] UserNamePasswordValidator: When DI and Framework collide

问题描述

我正在为一个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和框架冲突时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！