在子应用程序中阻止 web.config 继承

awj*_*awj 6 c# web-config subapplication secretsmanager asp-net-config-builders

我们有一个遗留的 .NET 解决方案,它结合了 MVC 和 WebForms 的东西,以及一些 Web API 项目作为网站根目录下的应用程序。显然,这些 Web API 应用程序将继承网站的 web.config 设置。

我们还有另一个项目——一个有界上下文——用于 SSO 身份验证,它位于同一个根文件夹内,因此也继承了网站的 web.config 设置。这个有界上下文应用程序是用 .NET Core 构建的。

- wwwroot   // .NET Framework
    - API 1 // .NET Framework
    - API 2 // .NET Framework
    - ...
    - SSO / authentication // bounded context, built in .NET Core
Run Code Online (Sandbox Code Playgroud)

我们最近开始使用 Azure Key Vault 来存储我们的机密,为了在本地处理这些机密,我们使用了 secrets.xml 文件。所以根网站的 web.config 看起来像这样......

<configSections>
  <section name="configBuilders" ... />
</configSections>  

<configBuilders>
  <builders>
    <add name="Secrets" optional="false" userSecretsFile="~\secrets.xml" [elided attributes] />
  </builders>
</configBuilders>

<appSettings configBuilders="Secrets">
  <add key="a_key" value="value specified in secrets.xml" />
  ...
</appSettings>
Run Code Online (Sandbox Code Playgroud)

问题是:身份验证有界上下文项目抛出异常,因为它找不到Microsoft.Configuration.ConfigurationBuilders.UserSecrets程序集 - 因为它继承了网站的配置,它需要知道该配置部分的全部内容。

但是,如果在 .NET Core身份验证项目中引用该 NuGet 包,我会收到消息...

此包可能与您的项目不完全兼容。

...它会自动回滚。

因此,如果我无法UserSecrets在 .NET Core 子应用程序中引用程序集,那么如何让它识别<configBuilders>继承的配置文件中的部分?

我也试过删除元素......

<configSections>
  <section name="configBuilders" />
</configSections>
Run Code Online (Sandbox Code Playgroud)

...来自根配置文件,但是子应用程序看到该<configBuilders>元素并且无法识别它。

所以问题归结为:

  1. 子应用程序需要在其中<configBuilders>定义元素的 NuGet 包。
    如果不...
  2. 子应用程序看到<configSections>/<section name="configBuilders" />元素并需要知道它是在哪里定义的。
    或者,我<section name="configBuilders" />在子应用程序中删除该元素,然后...
  3. 子应用程序看到<configBuilders>元素并需要知道哪个配置部分定义了它。

awj*_*awj 0

我们是这样解决这个问题的:

  1. 创建了一个自定义配置部分,我们在其中声明秘密。
    对任何关注此内容的人的警告注意事项:为了在configBuilders自定义配置部分声明该属性,您还必须声明相应的实现SectionHandler<your-custom-config-section>-这是文档
  2. 将此自定义配置部分和自定义添加SectionHandler<T>到我们的顶级站点以及站点内的 API 项目,但不添加到 .NET Core 构建的 SSO/身份验证子应用程序
  3. 在顶级站点中,将自定义配置部分包装在<location path="." inheritInChildApplications="false">.

这样做的缺点是,我们必须使用自定义配置管理器获取秘密,而所有非秘密应用程序设置都是使用默认值获取的ConfigurationManager,但我没有检测到任何与此相关的代码味道。