Question

Mon application utilise WebRequest à certains moments pour obtenir des pages d'elle-même.

Cela ne devrait pas être un problème. Cela fonctionne très bien sur le serveur, qui est un "partagé". forfait d'hébergement avec confiance moyenne. J'utilise localement une stratégie de sécurité personnalisée basée sur une confiance moyenne, qui inclut les éléments suivants & # 8212; copié directement à partir de la stratégie de confiance moyenne par défaut:

<IPermission
  class="WebPermission"
  version="1">
    <ConnectAccess>
        <URI uri="$OriginHost
public override object GetEntity( System.Uri puriAbsolute, string psRole, System.Type pReturnType )
{
    return _baseResolver.GetEntity( puriAbsolute, psRole, pReturnType );
}
quot;/> </ConnectAccess> </IPermission>

La ligne incriminée est dans un XmlRelativeUrlResolver personnalisé:

 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)

L'URL demandée se trouve sur localhost, dans la même application que le demandeur. Voici le haut de la trace de la pile.

<*>

Quelqu'un voit le problème ici?

@Sijin: Merci pour cette suggestion. L’URL envoyée au résolveur est basée sur l’URL de la demande et j’ai confirmé dans le débogueur que l’accès au site à 127.0.0.1 donnait le même résultat.

Était-ce utile?

La solution 2

Mon ignorance. Je ne savais pas que le jeton $ OriginHost $ avait été remplacé à l'aide de l'attribut originUrl du niveau de confiance - je pensais qu'il venait simplement de l'URL de l'application. J'avais initialement laissé cet attribut vide.

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

Autres conseils

Est-ce que ça marche si vous mettez 127.0.0.1 au lieu de localhost?

Ce n'est peut-être pas la solution, mais lorsque j'ai vu votre message, je me suis souvenu de ce problème que j'avais rencontré il y a environ un an:

  

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

     

Vous recevez l'erreur 401.1 lorsque vous   parcourir un site Web qui utilise Integrated   Authentification et est hébergé sur IIS   5.1 ou IIS 6

Nous étions en train de créer un WebRequest pour supprimer une page et cela fonctionnait dans notre environnement de production car nous n'utilisions pas un nom d'hôte en boucle mais sur des ordinateurs de développement, l'accès nous était refusé (après l'application de Windows Server 2003 SP2). La seule différence, c’est qu’il s’agissait d’une authentification intégrée qui l’avait fait échouer ... cela fonctionnait lorsque la demande était anonyme (c’est pourquoi je ne suis pas sûr que ce soit la solution pour vous).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top