Хранение ключей API в UWP

Насколько я понимаю, в UWP нет системы конфигурационных файлов, такой как ConfigurationManager. Поэтому у меня вопрос, где мне разместить ключи API, которые должны различаться в разных средах? Я также хочу иметь возможность переключать среду после сборки, поэтому сохранение ключей в коде (с флагами компиляции) не вариант. Есть ли лучший способ сделать это?

Что составляет "среда", и как вы "переключить среду"? Почему нельзя хранить ключи в коде? Считаются ли эти ключи конфиденциальной информацией?

IInspectable 13.09.2018 11:57

Под средой я подразумеваю dev, qa / test или production. Я хотел бы использовать одну и ту же сборку во всех средах, но переключить ключи перед развертыванием в определенной среде (например, с файлами конфигурации). Репо является частным, поэтому я полагаю, что размещение ключей в коде нормально с точки зрения безопасности, но это невозможно, если одна и та же сборка должна использоваться для всех сред. Я использую Azure DevOps для сборки и развертывания. Приветствую любые предложения о том, как это сделать наиболее правильным способом.

figursagsmats 14.09.2018 14:19

Если вам нужно что-то "как [a] файл конфигурации", почему бы не использовать файл конфигурации?

IInspectable 14.09.2018 21:50

Я догадался, что ConfigurationManager не работает в UWP по какой-то причине, поэтому я спросил «правильный способ» сделать это.

figursagsmats 17.09.2018 10:31

Тот факт, что вы планируете использовать управлятьконфигурации, не означает, что вы должны использовать тип, имя которого содержит "управлять" и "конфигурация". Вы можете использовать стратегию любой, которая решает вашу проблему, например, добавление файла JSON в ваш пакет и доступ к нему через ms-appx:Схема URI. "Правильный путь" зависит от ответов на вопросы, которые я задал в предыдущем комментарии.

IInspectable 17.09.2018 11:37

Да, я это понимаю. Я знаю, как хранить и загружать файлы в UWP. Мне просто интересно, как другие решают эту проблему. Кроме того, почему ConfigurationMangager больше нет? Просто ищу идеи по этому поводу. Может быть, другие приложили усилия, чтобы проанализировать разные подходы? Небольшое обсуждение может быть поучительным! Итак, скажите, нет ли проблем, связанных с использованием файла конфигурации? Нет ли подводных камней в безопасности?

figursagsmats 17.09.2018 14:02
SQL Injection: Атаки в реальной жизни и как это вредит бизнесу
SQL Injection: Атаки в реальной жизни и как это вредит бизнесу
Один-единственный вредоносный запрос может нанести ущерб вашему бизнесу. Уязвимости вашего кода могут привести к:
0
6
697
1

Ответы 1

Настройки приложения предоставляет простой в использовании интерфейс программирования - пары key-value для хранения / извлечения данных - который похож на ConfigurationManager.

var localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;

localSettings.Values["APIKey_SIT"] = "Hello World";

В отличие от ConfigurationManager, который читает / записывает простую конфигурацию XML, настройки приложения представляют собой файл Settings.dat, который находится в папке Settings данных приложения и доступен только приложению.

Проблема в том, что вам нужно добавить эти настройки во время выполнения, и я думаю, что OP должны иметь их заранее.

Martin Zikmund 13.09.2018 11:03

Я подумал об этом, хороший момент. Но на самом деле conundrum, чтобы иметь возможность иметь заранее настраиваемые значения, неизбежен дополнительный файл (json / xml или что-то еще).

kennyzx 13.09.2018 11:53

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

kennyzx 13.09.2018 11:58

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

Martin Zikmund 13.09.2018 12:02

@mar: Вас хорошо поняли, когда вы неоднократно заявляли, что в скомпрометированной системе не является безопасным. Хотя это, несомненно, правда, но это мало помогает. Я обрисовал в общих чертах, как конфиденциальность реализована в PasswordVault, и объяснил, что он не обеспечивает дополнительную безопасность любой по сравнению с хранением пароля в виде простого текста в закрытом для приложения месте при запуске в скомпрометированной системе. Все это звучит как фундаментальное непонимание с вашей стороны того, как обеспечивается безопасность.

IInspectable 13.09.2018 13:08

Хорошо, можем мы отпустить, когда я заявляю, что принципиально не разбираюсь в безопасности :-D? Но, пожалуйста, напишите ответ, в котором описывается, как безопасно хранить учетные данные.

Martin Zikmund 13.09.2018 13:16

@mar: Поскольку я не получил ответа на свой запрос о разъяснении, вряд ли я буду давать какие-либо указания. Публикация ответов, основанных на догадках, даже при наличии образования, бесполезна. Мне совершенно непонятно, почему вы так нервничаете, когда получаете фактически верную информацию поддающийся проверке, которая доказывает вашу неправоту. Если вы считаете, что правы, у вас наверняка есть что-то более жизнеспособное, чтобы объяснить себя на техническом уровне.

IInspectable 13.09.2018 13:36

Я не говорю, что вы ошибаетесь или что-то в этом роде. Дополнительный уровень безопасности за счет шифрования файла, несомненно, того стоит, и я признаю, что должен был упомянуть об этом в ответе, а я этого не сделал, поэтому я был неправ. И дело в том, что PasswordVault рекомендуется Microsoft в качестве способа хранения учетных данных пользователей для приложений UWP, поэтому я упомянул об этом, ни меньше, ни больше. Я не хочу ни с кем спорить и не вижу причины, по которой, как вы думаете, я это делаю.

Martin Zikmund 13.09.2018 13:43

Другие вопросы по теме