Search code examples
asp.netsecurityconfigurationwebrequest

WebRequest from localhost to localhost : why is it being denied?

My app uses a WebRequest at certain points to get pages from itself.

This shouldn't be a problem. It actually works fine on the server, which is a "shared" hosting package with Medium trust. Locally, I use a custom security policy based on Medium trust, which includes the following — copied straight from the default Medium trust policy:

<IPermission
  class="WebPermission"
  version="1">
    <ConnectAccess>
        <URI uri="$OriginHost$"/>
    </ConnectAccess>
</IPermission>

The offending line is in a custom XmlRelativeUrlResolver:

public override object GetEntity( System.Uri puriAbsolute, string psRole, System.Type pReturnType )
{
    return _baseResolver.GetEntity( puriAbsolute, psRole, pReturnType );
}

The url being requested is on localhost, in the same application as the requester. Here's the top of the stack trace.

 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)

Anyone see the problem here?

@Sijin: Thanks for the suggestion. The url that gets sent to the resolver is based on the request URL, and I confirmed in the debugger that accessing the site at 127.0.0.1 yields the same result.

Solution

  • My ignorance. I didn't know that the $OriginHost$ token was replaced using the originUrl attribute of the trust level — I thought it just came from the url of the app. I had originally left this attribute blank.

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