Действительно ли возможно определить учетные данные прокси в Вашем web.config?
3 ответа
Да, возможно определить Ваши собственные учетные данные, не изменяя текущий код. Это требует маленькой части кода от Вашей части все же.
Создают блок, названный SomeAssembly.dll с этим классом:
namespace SomeNameSpace
{
public class MyProxy : IWebProxy
{
public ICredentials Credentials
{
get { return new NetworkCredential("user", "password"); }
//or get { return new NetworkCredential("user", "password","domain"); }
set { }
}
public Uri GetProxy(Uri destination)
{
return new Uri("http://my.proxy:8080");
}
public bool IsBypassed(Uri host)
{
return false;
}
}
}
Добавляют это к Вашему файлу конфигурации:
<defaultProxy enabled="true" useDefaultCredentials="false">
<module type = "SomeNameSpace.MyProxy, SomeAssembly" />
</defaultProxy>
Это "вводит" новый прокси в списке, и потому что нет никаких учетных данных по умолчанию, класс WebRequest назовет Ваш код сначала и запросит Ваши собственные учетные данные. Необходимо будет разместить собрать SomeAssembly в каталог bin приложения CMS.
Это - так или иначе статический код, и получить все строки как пользователь, пароль и URL, Вы, возможно, или должны были бы реализовать свое собственное ConfigurationSection или добавить некоторую информацию в AppSettings, который намного более легче.
Каталог поиски Services/LDAP может использоваться для служения этой цели. Это включает некоторые изменения на уровне инфраструктуры, но большинство продуктивных сред имеет такое условие
Хотя я не нашел хорошего способа указать учетные данные прокси-сети в файле web.config, вы можете обнаружить, что можете использовать решение без кодирования, включив его в свою сеть .config:
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy proxyaddress="proxyAddress" usesystemdefault="True"/>
</defaultProxy>
</system.net>
Ключевым ингредиентом для этого является изменение настроек IIS, гарантирующее, что учетная запись, которая запускает процесс, имеет доступ к прокси-серверу. Если ваш процесс работает под LocalService или NetworkService, это, вероятно, не сработает. Скорее всего, вам понадобится учетная запись домена.