weixin_39560207
weixin_39560207
2020-12-09 13:14

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

[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?

该提问来源于开源项目:aspnet/IISIntegration

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

11条回答

  • weixin_39560207 weixin_39560207 5月前

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

    capture

    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 5月前

    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.

    might be testing this config in Azure Apps soon.

    点赞 评论 复制链接分享
  • weixin_39559015 weixin_39559015 5月前
    • 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.
    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 5月前

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

    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 5月前

    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 ...

     json
    "Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0-*"
    
     c#
    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
    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <system.webserver>
        <handlers>
          <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourcetype="Unspecified"></add>
        </handlers>
        <aspnetcore processpath="..\teststandalone.exe" stdoutlogenabled="true" stdoutlogfile="..\logs\teststandalone">
          <environmentvariables>
            <environmentvariable name="ASPNETCORE_CONTENTROOT" value="../"></environmentvariable>
          </environmentvariables> 
        </aspnetcore>
      </system.webserver>
    </configuration>
    

    Nah ..... It's not called the "CRAPJOB" pattern ... it's the "NUTJOB" pattern. :smile: 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.

    点赞 评论 复制链接分享
  • weixin_39786850 weixin_39786850 5月前

    This issue is probably related, I perhaps should have created it here: https://github.com/aspnet/Home/issues/1645#issuecomment-230870188

    点赞 评论 复制链接分享
  • weixin_39680609 weixin_39680609 5月前

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

    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 5月前

    ~~Just to clarify one more point. I recall the conversations with 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().

    点赞 评论 复制链接分享
  • weixin_39781550 weixin_39781550 5月前

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

    点赞 评论 复制链接分享
  • weixin_39560207 weixin_39560207 5月前

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

    点赞 评论 复制链接分享
  • weixin_39729837 weixin_39729837 5月前

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

    点赞 评论 复制链接分享

相关推荐