Head-check on moving `web.config` back to `wwwroot`

[guardrex]

@JunTaoLuo @tracher @moozzyk

[Opened outside of the discussion on the announcement so that I can link/find it easier.]

Coming off of Publish for IIS changes to web.config location (Announcements/#173) and concern over accidental renaming or moving of web.config that would leak sensitive files, may I get a head-check for those wishing to put web.config back into wwwroot?

• Use .UseContentRoot("../") on WebHostBuilder
• Use .UseContentRoot(Directory.GetParent(Directory.GetCurrentDirectory()).FullName)
• Set processPath="..\my_app.exe" (self-contained) or arguments="..\my_app.dll" (portable)
• Set stdoutLogFile="..\logs\stdout" (presuming logs is in the content root)
• Move web.config to wwwroot
• Point the IIS website physical path to wwwroot

Seems ok in testing. Is that correct or would that break something?

[michael-jenkinson]

I second this. I too will be moving it back to be similar to RC1.

[guardrex]

Just to clarify one more point. I recall the conversations with @moozzyk on paths. I'm not asking about dev/test, where debugging might not like that .UseContentRoot("../") ... One could easily program around that if that's a problem for debugging. I'm asking about on the IIS server in production.

Debugging solved by swapping Directory.GetCurrentDirectory() into .UseContentRoot().

[muratg]

@guardrex did you get a chance to test it on Azure Websites?

[guardrex]

@muratg No. I only ran an IIS Local test. It would be good to know if this will break in Azure Apps.

[davidfowl]

Use .UseContentRoot("../") Seems non portable. It'll only ever work if always hosting on IIS, self host will fail.

[guardrex]

Kestrel runs it from the command line or double-clicking the .exe ...

[guardrex]

It fails in VS Code debug ...

App Started: 5/6/2016 4:20:39 AM
dbug: Microsoft.AspNetCore.Hosting.Internal.WebHost[3]
Hosting starting
Exception thrown: 'System.AggregateException' in Microsoft.AspNetCore.Server.Kestrel.dll

... but if you simply change the ../ to Directory.GetCurrentDirectory(), of course, it runs in debug.

@Bartmax might be testing this config in Azure Apps soon.

[moozzyk]

@guardrex - I actually think it could be possible to contain all the changes to web.config. Instead of changing the content root in the application you could try setting it as an environment variable (ASPNETCORE_CONTENTROOTKEY) in web.config. You would need to ensure that configuration is reading environment variables.

[guardrex]

@moozzyk There would be no effect on the app for debugging that way 👍, so that sounds very good. That would also be easy to roll into my GuardRex.AspNetCore.Server.IISIntegration.Tools <--- malware 😄. I'll test this approach on Saturday. Thx. /cc @Aequoris

[guardrex]

@moozzyk @Aequoris

Env Var Approach

I didn't fully implement it b/c I could see along the way that it was something I wasn't interested in using, but it was shaping up along the lines of the following. Please correct the pseudo-code for others. I actually stopped cold with what you see here ...

"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0-*"

using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddEnvironmentVariables(prefix: "ASPNETCORE_")
    .Build();
var contentRootPath = Environment.GetEnvironmentVariable("ASPNETCORE_CONTENTROOT") ?? 
        Directory.GetCurrentDirectory();
var host = new WebHostBuilder()
    .UseContentRoot(contentRootPath) ...;

web.config to be placed in wwwroot ...

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add 
          name="aspNetCore" 
          path="*" 
          verb="*" 
          modules="AspNetCoreModule" 
          resourceType="Unspecified" />
    </handlers>
    <aspNetCore 
          processPath="..\teststandalone.exe" 
          stdoutLogEnabled="true" 
          stdoutLogFile="..\logs\teststandalone">
      <environmentVariables>
        <environmentVariable name="ASPNETCORE_CONTENTROOT" value="../" />
      </environmentVariables> 
    </aspNetCore>
  </system.webServer>
</configuration>

Nah ..... It's not called the "CRAPJOB" pattern ... it's the "NUTJOB" pattern. 😄 This approach seems to do a lot of engineering for something that should be a simple workaround. That's too much crap floating around in my startup pattern, and I had no other interest in env vars, so it ends up bringing that into the app just for this one purpose.

Another option ... Hidden Segments

Going back to my earlier idea (and the one spelled out in the IIS doc): Leave web.config in the content root but leverage Request Filtering to protect known sensitive files. You know, a big aspect of "NUTJOB" is to keep server config at the absolute bare minimum, so I would want to implement this in web.config.

[EDIT] Found out the use of Hidden Segments must be done at the server level in IIS, and that cannot be configured by web.config. It can be configured manually or via PowerShell. I confirmed that this approach works.