DefaultNetworkCredentials имеет нулевые значения. Нужно подсказать пользователю ... как?

Question

При определенных обстоятельствах мое приложение для настольных компьютеров, использующее веб-службы SharePoint, в конечном итоге получает DefaultNetworkCredentials с нулевыми значениями, поэтому вызов не выполняется. Мне нужно получить учетные данные пользователей, но я не нашел простого способа сделать это.

Я рассматриваю возможность реализации решения, описанного в http://www.pinvoke.net/default.aspx/credui/CredUIPromptForCredentialsW.html

... однако, это все еще потребует, чтобы я обработал пароль, что я действительно предпочел бы не делать. Я посмотрел, но не смог найти более прямой метод, который запрашивает пользователя и возвращает NetworkCredential напрямую, без необходимости хранить пароль?

Спасибо

РЕДАКТИРОВАТЬ: Похоже, я не собираюсь найти именно то, что я ищу ... Мне придется самому подсказывать пользователю, когда это произойдет.

Однако, если я правильно интерпретирую некоторые из этих ответов, это может быть условием ошибки для DefaultNetworkCredentials, чтобы быть нулевым, как это, во-первых. Это тот случай? Есть ли способ принудительно заполнить DefaultNetworkCredentials, или это действительно простой кеш, который просто запоминает последний домен / идентификатор пользователя / пароль, использованный для целевого URI (в тот день? Это приложение / сеанс?).

Answer 1

Я не думаю, что вы можете избежать обработки в первый раз. Но вы подключитесь к диспетчеру учетных данных, чтобы они были кэшированы с этого момента. Вот статья о том, как это сделать . Это тяжело в p / invoke, но может дать вашим пользователям более последовательный опыт.

Answer 2

Я не знаю что-то, что обрабатывает пароль для вас, но SecureString может быть полезным.

Answer 3

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

Если вы не хотите, чтобы они могли входить в SharePoint иначе, чем текущая учетная запись (возможно, полезная функция).

.NET имеет код для работы с учетными данными, так почему бы не угадать это, перейдя во внешние библиотеки DLL и добавив еще одну зависимость в свое приложение?

Я недостаточно знаю о рисках безопасности кода в вашей среде, но я бы подумал, что сохранение объекта учетных данных только в памяти клиента будет "достаточно безопасным" для большинства ситуаций.