Блокировка наследования web.config в субприложении - PullRequest
Новая
       42

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

6 голосов
/ 07 мая 2020

У нас есть устаревшее решение. NET, которое сочетает в себе элементы MVC и WebForms, а также некоторые проекты веб-API в виде приложений на веб-сайте root. Очевидно, что эти приложения веб-API унаследуют настройки веб-сайта web.config.

У нас также есть другой проект - ограниченный контекст - для аутентификации SSO, который находится в той же папке root и, следовательно, также наследует сеть веб-сайта. настройки конфигурации. Это приложение с ограниченным контекстом было создано с использованием. NET Core. 

- wwwroot   // .NET Framework
    - API 1 // .NET Framework
    - API 2 // .NET Framework
    - ...
    - SSO / authentication // bounded context, built in .NET Core

Недавно мы начали использовать Azure Key Vault для хранения наших секретов, а для локальной работы с этими секретами мы используем секреты. xml файл. Итак, web.config веб-сайта root выглядит так ... 

<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>

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

Но если ссылка на этот пакет NuGet в. NET Core аутентификации project Я получаю сообщение ...

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

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

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

I Мы также пытались удалить элемент ... 

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 17 мая 2020

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

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

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

0 голосов
/ 17 мая 2020

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

...