Базовый докер ASP.net https в контейнерах службы приложений Azure - PullRequest
Новая
       34

Базовый докер ASP.net https в контейнерах службы приложений Azure

0 голосов
/ 03 июля 2018

Как заставить ядро ​​ASP.net работать в докере по SSL, который работает со службой приложений Azure для контейнеров?

У меня он работает по HTTP, но как только я пытаюсь привязать его к SSL, чтобы проверка ASP.NET для таких вещей, как oauth и даже swagger, работала должным образом, я не могу сказать, что «Невозможно настроить конечную точку HTTPS. Нет указан сертификат сервера, и сертификат разработчика по умолчанию не найден. " В образе только среды выполнения, который генерирует vs.net, нет способа запустить сертификаты разработки, и даже тогда это может показаться небезопасным и, возможно, из-за ошибок сертификатов в браузере.

В основном мне нужно, чтобы https работал с внешней конечной точки на всем пути, чтобы kestrel выполнял шифрование и т. Д., А не ngix или что-либо еще, работающее на внешнем прокси, как это происходит по умолчанию.

Это отлично работает в отладке vs.net, потому что не выдает никаких ошибок и работает, даже если он связан с https.

К сожалению, документация рассматривает только самые основные случаи использования и не описывает, как заставить настоящий веб-сайт https надежно работать с ядром aspnet и контейнерами приложений Azure.

1 Ответ

0 голосов
/ 03 июля 2018

После поиска везде я смог собрать кучу тупых ссылок и найти решение.

Kestrel будет в режиме HTTP, но ему будет сказано, что он находится в режиме HTTPS посредством ForwardedHeaders от обратного прокси. В случае Azure есть определенный набор, который вы должны использовать. Другие потребуют других опций и могут потребовать дополнительной настройки. Эта документация поможет вам в общем случае, но в ней нет того, что необходимо для Azure: Конфигурация обратного прокси-сервера и балансировщика нагрузки ASPNet Core

Если вы используете IIS, он работает только потому, что он встроен, или вы добавили UseIIS в прошлых версиях Core.

Для веб-служб Azure в контейнере ИЛИ в базе Linux необходимо добавить следующий пакет Nuget:

Microsoft.AspNetCore.HttpOverrides

Как только это будет добавлено в Configure in Startup.cs как самое первое, вам нужно добавить следующее: 

var forwardOptions = new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto,
    RequireHeaderSymmetry = false
};

forwardOptions.KnownNetworks.Clear();
forwardOptions.KnownProxies.Clear();

app.UseForwardedHeaders(forwardOptions);

Обратите внимание, что без KnownNetworks и KnownProxies Clear () он не будет работать. И это не будет работать без RequireHeaderSymmetry = false, поэтому вам нужно все это.

На ForwardedHeaders вы хотите попытаться избежать. Все или другой вариант, который указан в списке, потому что он имеет уязвимость безопасности.

Затем в настройках приложения необходимо добавить WEBSITES_PORT=80, ASPNETCORE_URLS=http://+:80 и ASPNETCORE_HTTPS_PORT=443. Пока все это не будет, вы продолжите получать немного другую ошибку.

Примечание: это не исправит валидатор Swagger. У него есть другие проблемы, потому что валидатор не прав. JSON все еще действителен, но домен другой, поэтому он выходит из себя. Самый простой способ решить эту проблему - установить параметры UseSwaggerUi.EnableValidator (null); 

  app.UseSwaggerUI(
        options =>
        {
            options.EnableValidator(null);                  
        });
...