UserNamePasswordValidator:当 DI 和框架发生冲突时

问题描述

我正在为 WCF 服务构建自定义 UserNamePasswordValidator.我正在将服务与 Autofac + WCF/多租户连接起来，所有这些都很好地结合在一起.但是我不确定使用什么策略来连接/实现这个身份验证类.

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) {
        ...
    }
}

然而，这并不是完全可能的，因为 WCF 使用 UserNamePasswordValidator 的方式(唯一的选择似乎是无参数构造函数).

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 配置巫术可以用来配置 UserNamePasswordValidator factory?
2. 如果否"，那么在这种情况下可以使用的最DI 正确"的回退策略是什么?

推荐答案

我在启动时或在自定义 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 和框架发生冲突时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！