This might be a borderline Server Fault-question, but here goes.
I have a IIS 6 where AspMaxRequestEntityAllowed="204800" in MetBase.xml, suggesting the upload file limit is 200kb, while <httpRuntime maxRequestLength="20192"/> in web.config allows for a 20mb upload - and the latter is what the application allows.
Why do web.config override MetaBase.xml? To me, that seems like an error of hirarchy. And where would I find a "centralized parameter" to config max limits for the entire machine the server is on, in case I don't want some web.config mishapp to allow for gigabytes of upload?
Web.config file is the last-point configuration manager and entries in it will override any entries made in the higher layers.
I.e. any settings made in machine.config file (which are applicable to all websites) will be overridden by web.config (applicable to only that website).
In fact you can have separate web.config file for each folder which will override your root level web.config.
This is the way hierarchy works you know.
I am not aware of MetaBase.xml but in your machine there are default configs available in folder
c:\Windows\Microsoft.Net\Frameworks\VERSION\Config
am sorry the exact name could be little different, but you will figure out easily, here you will find couple of different web.*.config files, in each of them you can configure and there is a way you can disallow this property to be changed at lower level, but I am not aware of how to do that.
Reading MS Documentation of httpRuntime says that max limit is anyway set to 4MB by ASP.NET itself. I will try to find how to block lower level to modify this element in their web.config.
Related
I'm getting started with request filters to block bot traffic.
I've started with an example .htaccess file, see here: IIS htaccess rule converter only importing 1 rule
I don't want to manually add a ton of rules through the clunky IIS interface, so I'd rather add them to a file directly. I thought these rules would be in the applicationHost.config (based on this post), but on opening %WINDIR%\System32\inetsrv\config\applicationHost.config, I don't see any of the rules.
I also saw this post, so I tried opening the file with Notepad++ as well as Windows Notepad, but I still don't see the rule I created in IIS.
Why not?
IIS has a distributed configuration system and as Lex Li mentions, a great resource to familiarize yourself with is: https://learn.microsoft.com/en-us/iis/get-started/planning-your-iis-architecture/the-configuration-system-in-iis-7
Your configuration changes undoubtedly went to a web.config file. The location the configuration goes to change based on configuration, but by default Request Filtering will go to the lowest configuration file for which you are setting. In other words, if you are configuring Request Filtering for a Site, it will go to that Site's web.config. If you are configuring at a subdirectory, it will go to that subdirectory's web.config. You can actually influence where the settings go (i.e. site specific config can go to ApplicaitonHost.config) and its far easier thru command line.
If you look at the AppCmd.exe sampe in the ScanHeaders documentation, those commands will make changes (by default) to the Default Web Site's web.config. You can append /commit:AppHost to the end of them to make the settings apply to the ApplicationHost.config.
I've had a very frustrating experience on putting an MVC 5 app on Azure. I have been reading the following page: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure
But what I haven't managed to put in my head is the following:
Security Warning: Do not add your secrets .config file to your project or check it into source control. By default, Visual Studio sets the Build Action to Content, which means the file is deployed. For more information see Why don't all of the files in my project folder get deployed? Although you can use any extension for the secrets .config file, it's best to keep it .config, as config files are not served by IIS. Notice also that the AppSettingsSecrets.config file is two directory levels up from the web.config file, so it's completely out of the solution directory. By moving the file out of the solution directory, "git add *" won't add it to your repository.
And:
Security Warning: Unlike the AppSettingsSecrets.config file, the external connection strings file must be in the same directory as the root web.config file, so you'll have to take precautions to ensure you don't check it into your source repository.
The problem is the following: When I upload the Web.config file with the external files without being included I get hit by "The System cannot find the file specified", so for it to go away I must include the .config files defeating the purpose of Microsoft's post.
I really really really do not understand. I have added the connectionStrings and appSetting's keys in Azure's portal. What is the correct and secured way of putting my passwords and secrets online? What am I missing? Is it because I'm running in Debug mode?
According to this:
How can I secure passwords stored inside web.config?
There is nothing to worry about accessing the Web.config file...
But that just defies Microsoft's post.
Thanks.
I find the following technique to be the easiest way to do this.
Instead of putting the deployment values of these settings into the web.config, I keep the test values in there instead. I then put the deployment values into the Application Settings section of the Azure Website via the Azure Portal:
When the website runs, these settings will take precedence over what is in the web.config. This helps me avoid externalized files, allows me to keep sane development configuration that the team can share, and makes deployment very easy.
The best way is to set your secrets in the Connection Strings section of the portal. Any values set there will override values you specify in your web.config file.
This way they are only exposed to people who have admin access over the site itself. Having full access to the source won't even be enough to get the secret values.
More details here
I understand that I can add the following to the web.config file:
<httpRuntime maxRequestLength="10096" executionTimeout="120"/>
This will increase the upload limit for the application. The problem is that the WEB.CONFIG file is part of the application and part of my installation. I have multiple customers with different values they want to use. The Web.config file is overwritten each time they install a new version of my application. Thus, this would overwrite any modifications to the upload size they might have made.
Currently I have my customers change the Machine.Config file, but this is really not the best solution as they are changing the parameters for the whole IIS Server.
I figured maybe I could have the customer add an App.Config to the folder, where they could set their own parameters. Since that file is not part of my installation, it would stay.
Has anyone else had this problem, figured out a way to work around having the customer have an ability to have their own custom config file that will not get overwritten when they install a new version of the application?
Thanks,
Cory
In web.config:
<httpRuntime configSource="httpRuntime.config"/>
In httpRuntime.config:
<httpRuntime maxRequestLength="10096" executionTimeout="120"/>
See the configSource attribute in General Attributes Inherited by Section Elements and SectionInformation.ConfigSource Property on MSDN for an explanation.
I would like to store some meta-information about a given site instance that can (a) be managed by that site instance and (b) persist clobbering of Web.config file.
The site will run in multiple environments (dev,testing,staging and production) and each environment can have different values for this metadata.
Note: All environments are running IIS 7.0+
The Root Web.config seems very appealing, as it is certainly outside of the website. Therefore, both files and databases can be changed while maintaining the metadata. I have seen how to modify the appSettings of the Web.config stored in the website, but is it possible to similarly modify the appSettings in the Root Web.config (Specifically within the proper directive)?
If you have other suggestions of approaching this problem, I would be very happy to hear them. Thank you!
would not use web.config for runtime modifications, that will cause the application to recycle, perhaps some other form of configuration file like app.config
if my assumption is incorrect and the web.config will not be edited after the application is started, then you can use WebConfigurationManager to access the file sections
Yes you can modufy the app settings within your web.config Just use the WebConfigurationManager class in the System.Web.Configuration namespace to create a Configuration object. This object could then be used to read and write changes to the web.config file.
You could then create your own "keys" or attributes that could be read as needed.
Depending upon what your attributes represent or if they need to be picked up by multiple environmnets from that server I would also look into making the modifications within the machine.config file as then those settings would apply to the enter machine and thereby picked up by multiple environments( if you are hosting multiple webapps from the server). This could save you time in modifying multiple web.config files and narrorw the storage or the metadata to one location vs. multiple config files in certain situations.
I have a config file linked from web.config e.g.
<features configSource="feature.config" />
When I make changes to the "feature.config" file the IIS application appears to restart, is this expected behaviour?
Yes, this is expected behaviour by default as typically any changes made to the web.config will cause an application restart however this can be overridden for app.config files. From the msdn:
Saving a Web.config file restarts the
application. You can alternatively use
the configSource attribute of
individual section elements to point
to a secondary configuration file that
does not cause an application restart
when it is changed.
Although you have moved some of your configurations into a linked config file they are still effectively part of your web.config file and any changes made there will have the same effect as if you made the change directly in the web.config file itself. However you can specify a section to not restart the application on change by using the restartOnExternalChanges attribute in the section definition. See here and here for further details. However, according to the documentation this is not valid for ASP.NET applications which makes the above statement a little misleading.