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

У меня есть служба приложений в Azure, работающая как API для разрабатываемой мной системы. Поскольку API отвечает за прямой доступ к базе данных, я, очевидно, не хочу хранить строки подключения в исходном коде, поэтому сохранил их в разделе «Строки подключения» в конфигурации службы приложений на панели управления Azure.

Мой код в значительной степени является точной копией этого >> https://github.com/medhatelmasry/JwtAuthentication/blob/master/JwtAuthentication/Startup.cs, за исключением того, что у меня есть проверка текущей конфигурации, в которой он запущен (отладка, выпуск и т. д.), так что когда я отлаживаю локально в Visual Studio Я использую соединение localdb (жестко запрограммировано). У меня есть файл appsettings.json, но в нем нет строк подключения, только настройки для аутентификации и ведения журнала JWT.

Когда это вызывается:

services.AddDbContext<ApplicationDbContext>(
            option => option.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

В Azure я получаю следующее:

Unhandled Exception: System.ArgumentNullException: Value cannot be null
Parameter name: connectionString

Я работал глупые часы за последнюю неделю, пытаясь заставить это работать, и ходил по кругу, я доводил себя до безумия. Результаты Google и StackOverflow были неоднозначными, поскольку на протяжении многих лет были разные ответы из разных версий Azure и ASP.NET Core. Как будто он вообще не может получить доступ к конфигурации Azure. Пожалуйста, обратитесь к ссылке выше, так как это та же настройка, что и у меня, и было много разных ответов, основанных на версиях и типах .NET (ядро или фреймворк).

Изменить: прочтите мой вопрос, строка подключения не хранится в файле проекта appsettings.json, она хранится в Azure, как показано ниже (я вычеркнул имена строк подключения, но они соответствуют тому, что находится в коде, и нет. не "DefaultConnection"):

«Строки


person ataraxia    schedule 22.08.2019    source источник
comment
Для Configuration.GetConnectionString () потребуется JSON, например: { "ConnectionStrings": { "DefaultConnection": "DB Connection String here" } }, как выглядит ваш файл настроек?   -  person juunas    schedule 22.08.2019
comment
Пожалуйста, прочтите мой вопрос еще раз, строка подключения не хранится в файле настроек, она хранится в Azure, в соответствии с инструкциями Microsoft. Скриншот добавлен.   -  person ataraxia    schedule 22.08.2019
comment
Просмотрите следующий stackoverflow.com/a/48959565/5233410   -  person Nkosi    schedule 22.08.2019
comment
Поставщик конфигурации переменных среды должен получить эти ... github.com/aspnet/Extensions/blob/master/src/Configuration/   -  person juunas    schedule 22.08.2019
comment
@Nkosi, похоже, может это исправить, попробую, когда я вернусь с работы   -  person ataraxia    schedule 22.08.2019
comment
@juunas Я думаю, что проблема в том, что я не добавляю явно переменные среды в свой код, поскольку я полагаюсь на то, что вызывает Startup, чтобы предоставить IConfiguration, который уже содержит эти данные, а это явно не так.   -  person ataraxia    schedule 22.08.2019
comment
Если вы не создаете конструктор конфигурации и используете построитель веб-хоста по умолчанию, переменные среды должны быть там.   -  person juunas    schedule 22.08.2019
comment
@juunas это не так, или, скорее, я предполагаю, что это не так, поскольку Azure генерирует исключение нулевой ссылки при попытке найти его. Я думаю, что ответ Nkosi может разобраться в этом, я думаю, что это может быть проблема с версией, нужно подождать, пока я не вернусь с работы.   -  person ataraxia    schedule 22.08.2019
comment
Вы можете просмотреть переменные среды службы приложения в разделе Инструменты разработки - ›Дополнительные инструменты. Это должно доказать, существует ли переменная окружения. Он должен быть в формате ConnectionStrings__DefaultConnection или ConnectionStrings: DefaultConnection (только для службы приложений Windows).   -  person David C    schedule 22.08.2019
comment
Также обратите внимание, что вы по-прежнему открываете строку подключения всем, у кого есть доступ к лазурному порталу. Следующим шагом будет использование Managed Identity и наличие строки подключения в KeyVault с еще большей безопасностью.   -  person David C    schedule 22.08.2019
comment
@ DavidC799 Первый комментарий, я тоже посмотрю на него. Во-вторых, я буду искать вместо этого Managed Identity, как только смогу избавиться от этой ерунды. На данный момент доступ к порталу есть только у меня. Конечно, если у кого-то есть доступ к порталу, он также может возиться с Managed Identities?   -  person ataraxia    schedule 22.08.2019
comment
@ DavidC799 Думаю, нет, этого там нет? imgur.com/a/VxlpOe5   -  person ataraxia    schedule 22.08.2019
comment
Вы находитесь на ВАШЕМ САЙТЕ.scm.azurewebsites.net/Env.cshtml? Вы должны увидеть множество настроек приложения.   -  person David C    schedule 22.08.2019
comment
@ DavidC799 Теперь это так, и я думаю, что вижу проблему. Моя строка подключения есть, но а) с нее удалены дефисы и б) она имеет префикс SQLCONNSTR_, а затем имя. Итак, если я установил его на портале как Here-Is-My-SQL-Name, фактическая настройка в службе приложения - SQLCONNSTR_HereIsMySQLName. Позже протестирую. Если это сработает, вы можете добавить это в качестве ответа, чтобы я мог его принять, поскольку именно это руководство привело меня к поиску фактических сохраненных значений.   -  person ataraxia    schedule 22.08.2019
comment
Не беспокойтесь, удачи!   -  person David C    schedule 22.08.2019
comment
@ DavidC799 ты абсолютный АЛМАЗ !!!! Это было из-за именования, если вы ответите, я приму его и дам еще несколько деталей, я иду спать!   -  person ataraxia    schedule 23.08.2019


Ответы (1)


Убедитесь, что имена ваших переменных действительны. Фактические переменные среды можно просмотреть на сайте SCM в разделе «Средства разработки» -> «Дополнительные инструменты» в колонке «Служба приложений».

Строка подключения, добавленная через раздел «Конфигурация портала» службы приложений с именем «DefaultConnection», в переменных среды будет выглядеть как SQLCONNSTR_DefaultConnection. Чтобы получить к нему доступ в коде, вы должны сделать configuration.GetConnectionString("DefaultConnection")

См. этот блог Microsoft для получения подробной информации о настройке значений конфигурации службы приложений.

person David C    schedule 23.08.2019
comment
Это была проблема. В моей строке подключения были дефисы, которые кажутся недопустимыми (я предполагаю, что все, что не является буквенно-цифровым, запрещено). Скажем, моей строкой подключения был The-SQL-Server, фактическая переменная, сохраненная Azure, была SQLCONNSTR_TheSQLServer, однако SQLCONNSTR_ считывается и удаляется Azure, поэтому для вызова этого кода вы должны использовать Configuration.GetConnectionString("TheSQLServer"). - person ataraxia; 23.08.2019
comment
Чтобы понять это, потребовалось очень много времени, и во всей документации Microsoft, которую я читал, нет упоминания о запрещенных символах для имен переменных Azure. - person ataraxia; 23.08.2019
comment
Да, я искал запрещенных персонажей, но тоже ничего не нашел. Вам точно разрешены двоеточия и подчеркивания, всего остального я бы активно избегал! - person David C; 23.08.2019
comment
Плохо, очень плохо. Я вижу, что мой комментарий был отредактирован, вероятно, для языка, но на этой неделе я потратил дурацкие часы, чтобы разобраться в этом, и я совсем НЕ доволен Microsoft, тем более что Azure фактически удалила то, что я введен в саму конфигурацию, но сохранил то же имя на панели инструментов. Всем, кто читает это, я бы посоветовал не рисковать и при необходимости придерживаться буквенно-цифровых символов в верблюжьей оболочке (что я и сделал). Просто нужно исправить строку подключения Managed Identity, которая сейчас сломана! умирает внутри немного - person ataraxia; 23.08.2019
comment
Значит, вы делаете это через KeyVault? - person David C; 23.08.2019
comment
Я не знаю, что делаю, ищу различные сообщения об исключениях и журналы, которые я получаю, тогда да, я думаю, мне действительно нужно использовать KeyVault. Документация и справка на форумах сильно застаиваются, руководство не совсем понятно :( - person ataraxia; 24.08.2019
comment
В продолжение этого я теперь использую назначенное системой удостоверение для доступа к базе данных, поэтому имя пользователя и пароль больше не хранятся в строке подключения. Первоначально у меня была проблема с отказом в доступе, но исходную настройку и исправление можно найти здесь ›› stackoverflow.com/questions/57650568/. Я подготовлю полное руководство по выполнению всего этого на портале, когда у меня будет возможность. - person ataraxia; 04.09.2019
comment
Очень хорошо, я не знал, что вы можете использовать System Identity для прямого доступа к БД! Я говорил о том, что у вас будет строка подключения в KeyVault, а у службы приложений будет прямое подключение к ней через системный идентификатор. - person David C; 05.09.2019
comment
Да, я заглянул в KeyVault и тоже подумал, что именно так мне придется это сделать, чего я не ожидал! Идентификация, управляемая системой, намного аккуратнее, а также, согласно моему сообщению, может быть установлена ​​специально для базы данных, а не для всего сервера db из-за необходимости предоставлять пользователя в базе данных. - person ataraxia; 05.09.2019