Комментарии 12
Не пробовали в CoreFx закомитить переключалку способа аутентификации?
Только что прочитал, что libcurl
выпиливают в .NET Core 2.1:
https://blogs.msdn.microsoft.com/dotnet/2018/02/27/announcing-net-core-2-1-preview-1/
Интересно, что как это обернётся для вас :)
Ваша новость одновременно и печалит, и радует ;)
Ну так приватный код на то и приватный, что б не через рефлексию его дёргать в продакшин коде.
Кстати, такой вопрос чем все- таки обусловлена использования Linux контейнера для интеграции с wcf, ntlm?
Спасибо, очень помогли материалы из статьи. Стало понятно куда копать. Добавлю свои пять копеек на схожую тему.
У нас в организации есть Dynamics CRM и к ней сгенерирован OData-клиент штатными средствами Visual Studio. В организации используются свои сертификаты.
Создаем контейнер из microsoft/aspnetcore
, как в шаблонах Студии. Сначала нарвались на System.Net.Http.CurlException: Peer certificate cannot be authenticated with given CA certificates
. Добавление сертов через update-ca-certificates
не помогло, libcurl в образе почему-то упорно игнорирует системное хранилище.
Окей, есть переменные SSL_CERT_DIR
и SSL_CERT_FILE
, но приложение, вызывающее libcurl, должно само передавать их. Dotnet core научился это делать с версии 2.1, которая еще в preview.
Обновляем SDK до 2.1 preview1, VS до 15.6 preview 7, и не забываем в докерфайле обновить базовый образ: microsoft/aspnetcore:2.1.0-preview1
, и добавляем в докерфайл переменные с путями к сертификатам.
После этого получаем System.Net.Http.CurlException: SSL peer certificate or SSH remote key was not OK
. Оказывается, SSL_CERT_DIR
почему-то ничего не дает, поэтому придется упаковать все сертификаты в один .pem
файл и указать его в SSL_CERT_FILE
(разработчик curl называет это "bundle", пример есть на его сайте). Это решает все проблемы с сертификатами.
А еще OData-клиент в .net core нормально работает c NTLM под линуксом, а под windows падает с DataServiceClientException: HTTP Error 401 - Unauthorized: Access is denied
. Я завел баг, но ответа нет, и к сожалению OData-клиент не так хорошо поддается расширяемости, как WCF…
Пока решил обойтись тем, что под Windows (на машинах разработчиков, у кого не настроен докер) приложение будет запускаться на полном .net Framework, для этого есть multi target: в .csproj нужно написать <TargetFrameworks>net471;netcoreapp2.0</TargetFrameworks>
. Но тогда разваливается билд, т.к. поддержка этой фичи еще фиговая и студия не знает, что делать с docker-проектом при сборке net471. Если выгрузить этот проект, то все собирается и работает нормально на полном фреймворке.
Анатомия .NET Core: как мы настроили NTLM под Linux