Блокировка наследования web.config в подприложении

У нас есть устаревшее решение .NET, в котором есть комбинация материалов MVC и WebForms, а также некоторые проекты веб-API в виде приложений в корне веб-сайта. Очевидно, что эти приложения веб-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

Недавно мы начали использовать 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>

Вот в чем проблема: проект ограниченного контекста Аутентификация выдает исключение, потому что не может найти сборку Microsoft.Configuration.ConfigurationBuilders.UserSecrets, поскольку он наследует конфигурацию веб-сайта, и ему необходимо знать, о чем этот раздел конфигурации.

Но если сослаться на этот пакет NuGet в проекте authentication .NET Core, я получаю сообщение...

Этот пакет может быть не полностью совместим с вашим проектом.

... и он автоматически откатывается.

Итак, если я не могу сослаться на сборку UserSecrets в подприложении .NET Core, то как я могу заставить его распознавать раздел <configBuilders> в унаследованном файле конфигурации?

Я также попытался удалить элемент...

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

...из корневого конфигурационного файла, но субприложение видит элемент <configBuilders> и не распознает его.

Итак, проблема сводится к следующему:

  1. Подприложению требуется пакет NuGet, в котором определен элемент <configBuilders>.
    Если нет...
  2. Подприложение видит элемент <configSections> / <section name="configBuilders" /> и должно знать, где он определен.
    Или я удаляю этот элемент <section name="configBuilders" /> в подприложении, а затем...
  3. Подприложение видит элемент <configBuilders> и должно знать, в каком разделе конфигурации он определяется.

person awj    schedule 07.05.2020    source источник


Ответы (2)


Опубликуйте WEB API в другом виртуальном каталоге. Создайте правила перенаправления или перезаписи, чтобы направить трафик веб-API в этот виртуальный каталог.

person AllWorkNoPlay    schedule 17.05.2020

Вот как мы решили эту проблему:

  1. Создан пользовательский раздел конфигурации, в котором мы объявляем секреты.
    Примечание для всех, кто следует этому: чтобы объявить атрибут configBuilders в пользовательском разделе конфигурации, вы также должны объявить соответствующую реализацию SectionHandler<your-custom-config-section> - вот документация.
  2. Этот настраиваемый раздел конфигурации и настраиваемый элемент SectionHandler<T> добавлены на наш сайт верхнего уровня и в проекты API на сайте, но не в встроенное в .NET Core приложение единого входа/аутентификации.
  3. На сайте верхнего уровня обернул пользовательский раздел конфигурации в <location path="." inheritInChildApplications="false">.

Недостатком этого является то, что мы должны получать секреты с помощью нашего пользовательского диспетчера конфигурации, в то время как все несекретные настройки приложений получаются с использованием ConfigurationManager по умолчанию, но я не обнаруживаю в этом никакого запаха кода.

person awj    schedule 17.05.2020