2008-10-01 1 views
0

Мое приложение использует WebRequest в определенных точках, чтобы получать страницы от себя.WebRequest от localhost до localhost: почему это отрицается?

Это не должно быть проблемой. На самом деле он отлично работает на сервере, который является «общедоступным» пакетом хостинга со средним доверием. Локально, я использую политику пользовательских безопасности на основе среднего доверия, который включает в себя следующие — скопированные прямо из среднего доверия политики по умолчанию:

 
<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 дает тот же результат.

ответ

0

Мое невежество. Я не знал, что токен $ OriginHost $ был заменен с использованием атрибута originUrl уровня доверия — Я думал, что он только что появился из URL-адреса приложения. Я изначально оставил этот атрибут пустым.

 
<trust level="CustomMedium" originUrl="http://localhost/" /> 
1

Это работает, если вы поставили 127.0.0.1 вместо localhost?

+0

Спасибо за предложение. URL-адрес, который отправляется в преобразователь, основан на URL-адресе запроса, и я подтвердил в отладчике, что доступ к сайту в 127.0.0.1 дает тот же результат. – harpo 2008-10-01 15:43:41

0

Это не могло бы быть решение, но когда я увидел вашу почту, я вспомнил этот вопрос, что я столкнулся около года назад:

http://support.microsoft.com/default.aspx/kb/896861

Вы получите ошибку 401.1, когда вы просматривать веб-сайт, который использует встроенный Аутентификация и размещается на IIS 5.1 или IIS 6

Мы создавали WebRequest для скрининга страницы и работали в нашей производственной среде, потому что мы не использовали имя хоста loopback, но на машинах разработки мы закончили с отказом доступа (после применения Windows Server 2003 SP2). Единственное различие здесь заключается в том, что это было под интегрированной аутентификацией, которая привела к ее провалу ... она работала, когда запрос был анонимным (поэтому я не уверен, что это ответ для вас).

+0

Спасибо. Я нашел проблему, как отмечалось, но я также сталкивался с чем-то вроде того, о чем вы говорите. WebRequest не получает отправленные с ведущими учетными данными способы, которые делают запросы от браузера; вы должны «вручную» добавить их в заголовки запроса, как я уверен, вы узнали. – harpo 2008-10-01 20:07:54

Смежные вопросы