In legacy ASP.NET applications, *.config files cannot be downloaded by navigating to the URL. But the new convention is to use appsettings.json. Now, if I have a ASP.NET Core website called contoso.com and it's served by IIS from a directory called C:\inetpub\websites\contoso.com, and there is a file located at C:\inetpub\websites\contoso.com\appsettings.json... Is IIS smart enough to know not to serve this file over HTTP if someone navigates to https://contoso.com/appsettings.json?
Files are normally served from the "wwwroot" folder. The appsettings.json file is safe as long as you haven't configured C:\inetpub\websites\contoso.com\ to be your app's web root. By default, static files are found in C:\inetpub\websites\contoso.com\wwwroot\. I recommend this excellent doc: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/static-files
By the way, unless configured otherwise, IIS doesn't even check the filesystem. It is actually ASP.NET Core that is going to ensure files are only served from the "wwwroot" folder. A typical ASP.NET Core website in IIS is actually running as a separate web server which IIS reverse proxies to via the ASP.NET Core Module. This means all requests are handled by ASP.NET Core. To serve static files, you have to use the static files middleware, which is available in the Microsoft.AspNetCore.StaticFiles package.
Related
When using selfhost .Net Core 2.x, all the build artifacts are statically served by default, since the default directory is the same place as the binary/exe.
This means if one knows the names of the dlls, they can just request
them at /Whatever.dll, or they can also get any config files by name,
i.e. appSettings.
If you change things so that that the root directory is different or that directory is not in the VFS, /metadata stops working.
Is it possible to have /metadata work, but not allow the service's dlls etc to be statically served?
I have tried restricting the paths. This will keep settings / dlls / exes from serving, but the /metadata page will come up completely blank.
The /metadata page isn't related to the static file directory location, you may have caused a Startup Exception that's impacted how it works. If you can put together a stand-alone project on GitHub which shows the issue I can investigate.
Only extensions in Config.AllowFileExtensions can be served, you can remove .dll from being served with:
Config.AllowFileExtensions.Remove("dll");
.exe aren't servable by default, if you can download them you might be downloading them with .NET Core's static file handler instead.
It's common practice to have the WebRoot outside of the project root which for .NET Core is typically /wwwroot.
edit: Updated suggestion to remove the badness.
What I ended up doing at first was to add a .UseWebRoot() onto the
builder, then later switched from the selfhost ServiceStack template
to the web template per Mythz's suggestion. The web template was
set up in a way that solved my problem.
Thanks again.
for example, there is an application written using dot net core 2.1
Published under the IIS (Windows Server 2016). At the root of the application (near to the binaries (.dll)) random files are being created and modified. Will this affect the performance of the application? Will it make a difference if these files are created in a subdirectory next to the binaries?
If we exclude IIS and host under Kestrel, will it affect somehow?
As far as I remember, when hosting applications, written on a .NET fullframework, under IIS, and modifying any file (for example, a text file) in the BIN directory resulted in restarting the web application.
I do not know what files are being created and modified i would separate them form the app files for security reasons to say the least. Having said that to answer your question.
It should not affect the performance unless the volume of operations is so large that it will use up all iops on the drive or the pc/ram of the machine.
Kestrel will not be affected unless you try to modify files that kestrel uses for the app in some way and if you use dotnet watch run it will try to recompile them and run in the host if not it will ignore their existence until the host is restarted.
IIS should ignore them as well but i do not know what will happen if you have those files in bin and try to restart the host. i have tried changing and adding a file and did not restart. Maybe there is something in IIS settings but since i have not setup our IIS my answer is lacking in that regard.
I am trying to find out how to host an ISAPI DLL in Azure. In addition to the DLL, I'll need to deploy supporting files in subdirectories (javascript & css files). And two of these subdirectories can have their contents changed by requests handled by the DLL, so I need to ensure that the account executing the extension has write permission for these.
It would seem that the key to all of this is using a startup task to call appcmd to script all the IIS changes somehow, and I think I need to do the following:-
Deploy my ISAPI DLL and supporting files with my ASP.NET website
Create a startup task which will call a batch file utilizing appcmd.exe to do the following:-
Create a dedicated app pool with its managed pipeline mode set to Classic, and using a known user account
Create an IIS application pointing to the directory where my ISAPI dll resides
Ensure the application is configured to allow unknown ISAPI extensions
Alter the permissions of the required subdirectories so the user account associated with the app pool has write access
I've only just started exploring Azure, so my experience with it is very thin on the ground. Is what I'm hoping to achieve actually achievable? And if so, am I on the right track with regards to the steps required? They mimic what I need to do if I'm setting up this ISAPI DLL in the traditional IIS environment I'm used to dealing with, but please let me know if the rules are different with Azure.
Looks like a good sequence, however, the startup tasks actually run before IIS is completely configured. The 'OnStart' event in the RoleEntryPoint is called after IIS is set up, so it's probably easier to use the IIS application that Azure creates for you, and reconfigure it to include your ISAPI stuff.
Well the only thing bothering me here is that you're modifying data on the 'deployment drive' (E: for that matter). You shouldn't be doing this.
Instead, think of an other solution. You could create a LocalResource holding your javascript and CSS files. Then, when your role starts (Richard has a valid point about startup tasks), use ServerManager class to do the following:
Register the ISAPI dll
Add 2 virtual directories under the website created by Azure and point them to the LocalResource.
Modify the code of your ISAPI dll to modify JS/CSS files in the LocalResource
When developing in Web/WorkerRoles, you need to keep in mind that you should only manipulate files in a LocalResource.
I am aware that any change to ANY file in the BIN directory will trigger an application restart in IIS. Are there any other "special" cases where changing a file or moving a file in any other directory will trigger an app restart?
I know this is a very old post, but may be helps someone:
See this: http://programming360.blogspot.com/2009/04/what-causes-application-restart.html
ASP.net run-time environment implements a good deal of checks and automatically restarts an application if any of the following scenarios occur:
The maximum limit of dynamic page compilations is reached.
The physical path of the Web application has changed, or any
directory under the Web application folder is renamed.
Changes occurred in global.asax, machine.config or web.config in the
application root, or in the Bin directory or any of its
subdirectories.
Changes occurred in the code-access security policy file, if one
exists. Too many files are changed in one of the content directories.
(Typically, this happens if files are generated on the fly when
requested.)
Changes occurred to settings that control the restart/shutdown of the
ASP.NET worker process. These settings are read from machine.config
if you don't use Windows 2003 Server with the IIS 6.0 process model.
If you're talking full advantage of IIS 6.0, an application is
restarted if you modify properties in the Application Pools node of
the IIS manager.
If you change the web.config you app domain should also be reloaded and assemblies flushed.
I have a default IIS 6 install and I can access only .html files. If I create a html file I can see it on the browser. Any other files like ini for example are not visible (404). Any idea on what can be the issue?
Check the web service extensions are enabled (in IIS below the websites is a folder for them) for the content you are trying to share.
Check that the handler mappings is setup correctly (on the website properties)
This may help :
IIS & ASP.NET blocking file