Мое приложение использует WebRequest в определенные моменты для получения страниц от самого себя.
Это не должно быть проблемой. На самом деле он отлично работает на сервере, который представляет собой «общий» хостинг-пакет со средним уровнем доверия. Локально я использую настраиваемую политику безопасности, основанную на среднем уровне доверия, которая включает в себя следующее - скопированное прямо из политики среднего доверия по умолчанию:
<IPermission
class = "WebPermission"
version = "1">
<ConnectAccess>
<URI uri = "$OriginHost$"/>
</ConnectAccess>
</IPermission>
Оскорбительная строка находится в настраиваемом XmlRelativeUrlResolver:
public override object GetEntity( System.Uri puriAbsolute, string psRole, System.Type pReturnType )
{
return _baseResolver.GetEntity( puriAbsolute, psRole, pReturnType );
}
Запрашиваемый URL-адрес находится на локальном хосте в том же приложении, что и запрашивающая сторона. Вот вершина трассировки стека.
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) at System.Security.CodeAccessPermission.Demand() at System.Net.HttpWebRequest..ctor(Uri uri, ServicePoint servicePoint) at System.Net.HttpRequestCreator.Create(Uri Uri) at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase) at System.Net.WebRequest.Create(Uri requestUri) at System.Xml.XmlDownloadManager.GetNonFileStream(Uri uri, ICredentials credentials) at System.Xml.XmlDownloadManager.GetStream(Uri uri, ICredentials credentials) at System.Xml.XmlUrlResolver.GetEntity(Uri absoluteUri, String role, Type ofObjectToReturn) at flow.controls.XmlRelativeUrlResolver.GetEntity(Uri puriAbsolute, String psRole, Type pReturnType) in c:\flow\source\controls\DataTransform.cs:line 105 at System.Xml.Xsl.Xslt.XsltLoader.CreateReader(Uri uri, XmlResolver xmlResolver)
Кто-нибудь видит здесь проблему?
@Sijin: Спасибо за предложение. URL-адрес, который отправляется преобразователю, основан на URL-адресе запроса, и я подтвердил в отладчике, что доступ к сайту по адресу 127.0.0.1 дает тот же результат.





Работает, если вместо localhost поставить 127.0.0.1?
Мое невежество. Я не знал, что токен $ OriginHost $ был заменен с использованием атрибута originUrl уровня доверия - я думал, что он просто пришел из URL-адреса приложения. Изначально я оставил этот атрибут пустым.
<trust level = "CustomMedium" originUrl = "http://localhost/" />
Возможно, это не решение, но когда я увидел ваш пост, я вспомнил об этой проблеме, с которой столкнулся около года назад:
http://support.microsoft.com/default.aspx/kb/896861
You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or IIS 6
Мы создавали WebRequest для очистки страницы от экрана, и он работал в нашей производственной среде, потому что мы не использовали имя хоста с обратной связью, но на машинах разработки мы получили отказ в доступе (после применения Windows Server 2003 SP2). Единственное отличие здесь в том, что это было при интегрированной аутентификации, что привело к сбою ... он работал, когда запрос был анонимным (поэтому я не уверен, что это ответ для вас).
Спасибо. Я обнаружил проблему, как указано выше, но я также столкнулся с чем-то вроде того, о чем вы говорите. WebRequest не отправляется с президентскими учетными данными, как запросы из браузера; вы должны «вручную» добавить их в заголовки запросов, как я уверен, вы уже узнали.
Спасибо за предложение. URL-адрес, который отправляется преобразователю, основан на URL-адресе запроса, и я подтвердил в отладчике, что доступ к сайту по адресу 127.0.0.1 дает тот же результат.