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

本文介绍了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).

所以，问题:

我是否正确或者是否有一些 WCF 配置巫术可以用来配置 UserNamePasswordValidator factory?

如果否"，那么在这种情况下可以使用的最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>();