|

«Использовать мои учетные данные Windows» требует субъекта. В настольной программе это может быть человек, который ее запускает. В службе это может быть учетная запись службы. В веб-приложении успешный вход посетителя не заменяет автоматически контекст безопасности исходящего запроса.

Это объясняет, почему браузер и серверный код на одной и той же машине могут получать разные результаты от прокси с интегрированной проверкой подлинности. Возможно, они предъявляют разные удостоверения.

Назовите удостоверения, прежде чем менять код

  • Человек, вошедший в настольный браузер.
  • Учетная запись, в которой размещен процесс приложения.
  • Любое олицетворенное удостоверение, активное для исходящей операции.
  • Учетная запись, которую прокси действительно принял или отклонил.

На поддерживаемых .NET путях интегрированной проверки подлинности DefaultCredentials относится к текущему контексту безопасности. Это не глобальный псевдоним для всякого, кто открыл страницу на другой машине.

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

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

Похожие статьи