Some files are not served off of IIS because they are typically part of the building blocks of the website itself. For ASP.NET these are files like *.cs, *.dll, *.config, *.cshtml, etc.
You can find a list of them tied up in the IIS management setting "Filter requests" here:
But if you need to programmatically access this list, it seems tough to find. Is there a good list of these default extensions?
BTW, the IIS website has info on how to enable / disable these globally here:
http://www.iis.net/configreference/system.webserver/security/requestfiltering/fileextensions
If I'm not mistaken, you'll find them in the root web.config of the machine:
%windir%\Microsoft.NET\Framework\framework_version\CONFIG
Which is also where you'll find the machine.config file.
e.g.
<add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" />
REF:
Technet: working with config files
KB: Use ASP.NET to Protect File Types
As to how you'd programmatically get to it - I haven't tried. The IIS_USRS built-in group has access to it and this doc expands on it.
Hth...
Here's the list I build out of the IIS UI since I couldn't find it anywhere. Hope you find it helpful.
disallowed extensions
.asax
.ascx
.master
.skin
.browser
.sitemap
.config
.cs
.csproj
.vb
.vbproj
.webinfo
.licx
.resx
.resources
.mdb
.vjsproj
.java
.jsl
.ldb
.dsdgm
.ssdgm
.lsad
.ssmap
.cd
.dsprototype
.lsaprototype
.sdm
.sdmDocument
.mdf
.ldf
.ad
.dd
.ldd
.sd
.adprototype
.lddprototype
.exclude
.refresh
.compiled
.msgx
.vsdisco
.rules
on localhost you can alter the applicationHost.config file, a systems file that you can edit in VS and go to the requestFiltering section, change and save.
Related
Is there a way to tell IIS to read configurations from a different file than web.config?
Why would anyone do this?
Convenience. When working with static resources like an .aspx, or .js, or an MVC view file, it is often sufficient to hit Refresh in the browser to see the effect of that change.
Also, more specific to our scenario is that we re-use some of our code-base in different flavors of the web site, their differences being defined in their respective .config files, and each of these sites run locally on our development clients.
Getting the change to a different location than the one you are actually working in is somewhat time-consuming: A Publish operation will properly compile and copy the entire web application to the target location, copying the individually changed file manually is often... fiddly.
So what I would like for to be possible is this:
I work on my project in c:\workbench\FlavMaster3000. In this folder I create the various flavors of web.config files:
web.apple.config
web.banana.config
web.cherry.config
I create sites in IIS that represents each flavour and set their directory to the same as above.
https://local-apple/
https://local-banana/
https://local-cherry/
And I would like for IIS to read each site's configurations from the respective flavor of .config.
Is this at all possible, or am I a dreamer with a hopeless dream?
-S
You can put your specific configuration in external file(s) and link those files in your web.config file as shown below. However downside is way web.config is watched for any changes in it and gets applied immediately when you save web.config, these external files will not be monitored and you will require to manually restart app pool.
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<appSettings configSource="Myconfigs/myappSettings.config"/>
<connectionStrings configSource="Myconfigs/myconnections.config"/>
<system.web>
<pages configSource="Myconfigs/mypages.config"/>
<profile configSource="Myconfigs/myprofile.config"/>
<httpHandlers configSource="Myconfigs/myhttpHandlers.config"/>
<httpModules configSource="Myconfigs/myhttpModules.config"/>
</system.web>
</configuration>
I have an <applicationSettings> tag in my web.config file which contains <connectionString> and other settings related to the application.
I want to ask If I want to add some more settings to the <applicationSettings> section. How can I do that?
Is it possible to edit/add tags in the <applicationSettings> section of the web.config file?
You mean at runtime? When the application is published? Sometime else? The config file can be edited within Visual Studio.. or even just good ol' notepad. You can definitely edit it, you just need to follow the appropriate XML structure provided, meaning appsetting keys use a NameValueCollection - http://msdn.microsoft.com/en-us/library/vstudio/ms228154(v=vs.100).aspx
We have a whole bunch of websites with very similar web.config files.
Can you centralise the duplicate configs in 1 config file before the root directory of each website? Or is the only option machine.config?
We are looking to centralise an assembly reference in the GAC.
Structure:
Containing Directory
Website 1 Directory
Website 2 Directory
Website 3 Directory
Web.Config File for all above sites
I have not encountered a way to have inherited config files besides machine.config, app/web.config and user.config levels. But you can use configSource attribute on all config sections (ConfigurationSection based) to include a common file for example with service endpoints, client endpoints, bindings, connection strings and others. Even though VS intellisense marks it as unsupported it does work.
<configuration>
<system.serviceModel>
<services configSource="Services.config" />
<client configSource="Client.config" />
<bindings configSource="Bindings.config" />
<behaviors configSource="Behaviors.config" />
</system.serviceModel>
<pages configSource="pages.config"/>
</configuration>
Config source files must be in application's folder or any folder below. No going up or absolute paths. But there is a trick to overcome this limitation in VS2010. You need to add an existing file as a link and change its property named "Copy to Output Directory". This way your absolute path file will get copied to your application folder from where you can reference it in configSource.
In previous versions of VS it is also possible but in a less elegant way - copy file in post build event.
If you are looking mainly to centralize WCF settings there is another option: in-code configuration. Huge advantage of this is you get compilation-time check and refactoring support from VS. If this does not sound like much I can assure you that in a bigger WCF project, config file management is a nightmare especially when you need to change something. With this approach it is also very easy to centralize WCF settings by just creating a common assembly where all services, endpoints, bindings etc. are defined. Disadvantage is that you loose possibility to change WCF settings without recompilation. But if those settings do not change very often it is a tempting alternative.
You can use the web.config located in
%SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\Web.config
Or if in IIS you configure your Containing directory as a main web site and then put your website directories as applications, you can put the web.config in the main web site to have the structure you mention.
The application folders in ASP.NET are used for storing various elements critical to running a website. I want to get a handle on understanding these folders in more depth, specifically the folder accessibility. According to the article on ASP.NET Web Site Layout:
The content of application folders,
except for the App_Themes folder, is
not served in response to Web
requests, but it can be accessed from
application code.
Any browser request to these folders results in a "404 - Page Not Found."
So what prevents folders like App_Code, App_Data, App_WebReferences, bin, etc. from being served to users? Is it an IIS hard coded "don't serve this folder?" Is it a permissions configuration? And is there anyway to knowingly/unknowingly circumvent this?
On my IIS7.5 config, found at C:\Windows\System32\inetsrv\config\applicationHost.config there is this section:
<hiddenSegments applyToWebDAV="true">
<add segment="web.config" />
<add segment="bin" />
<add segment="App_code" />
<add segment="App_GlobalResources" />
<add segment="App_LocalResources" />
<add segment="App_WebReferences" />
<add segment="App_Data" />
<add segment="App_Browsers" />
</hiddenSegments>
See also IIS Documentation.
In IIS7 on Windows Server 2008, ASP.NET is more tightly integrated into the entire processing pipeline, so I would imagine that in IIS7, it is very easy for ASP.NET to say "No, I'm not going to touch that."
In IIS6, IIS itself has very little direct knowledge of IIS, instead, it's all controlled through the ISAPI configuration.
In the IIS6 IIS Manager, right click a website, get Properties, go to the Home Directory tab, and then click Configuration in the lower right. This shows the ISAPI application extensions and what is done for each one.
For all the ASP.NET extensions (aspx, ascx, config, browser, a ton of others) it specifies handling to be done by C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
The ASP.NET system then has registered handlers for each of these file types defined in the global machine.config and/or web.config files at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
For instance, in the global web.config file, under httpHandlers element:
<add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
So it is not just these special folders, but many types of files, but many types of reserved files that are disallowed from browsing.
The .net framework itself intercepts requests to these folders (along with a bunch of other file types that you should be allowed to browse) and returns a 404 to IIS, which then gets passed back to the browser as "404 - Page Not Found".
So it doesn't happen at the permissions level, or even the IIS level. It's inside the framework -- probably in one of the HttpHandlers in the global web.config.
If you look in there, you can see a ton of file extensions that are explicitly configured to not be served. Presumably you could tweak the settings and cause it to serve, say, web.config files as xml (which is different than the usual behavior of saying that this file type is not served).
It's worth noting that I don't specifically see any of the special folders (app_code, etc) mentioned in the global web.config file. Maybe it's handled inside other HttpHandlers -- for instance, the handler for .aspx might contain some code that prevents serving of .aspx files located in special folders, etc.
On Apache/PHP sites if I want to put a senstive file within my website folders, I put a .htaccess file in that folder so users can't download the sensitive file.
Is there a similar practice for IIS/ASP.NET sites, i.e. if I have a shared hosting account and don't have access to IIS server. Can I do this in web.config for instance?
e.g. the ASPNETDB.MDF file that ASP.NET Configuration put in the App_Data directory. I would assume this is protected by default but where can I change the settings for this folder as I could with a .htaccess file?
Inside of an ASP.Net web.config you can setup locations to add security to specific files and folders. In addition, you can remove all verbs from those directories:
<location path="Secret" allowOverride="false">
<system.web>
<authorization>
<deny users="*" />
</authorization>
<httpHandlers>
<remove path="*.*" verb="*"/>
</httpHandlers>
</system.web>
</location>
I have only used the authorization portion of that snippet and it works great. The handler should further lock it down and using a ISAPI filter would be able to put the finishing touches on it.
Well, if you can access IIS settings, UrlScan can help. For IIS 7, request filtering can help a lot.
http://learn.iis.net/page.aspx/473/using-urlscan
http://learn.iis.net/page.aspx/143/how-to-use-request-filtering/
There are some things you can do with web.config like defining security settings etc...
Other times you have to use HttpModules or HttpHandlers, look here:
http://msdn.microsoft.com/en-us/library/aa719858(VS.71).aspx
If not, you can find different ISAPI, but in this case you need access to IIS.
For example, the ISAPI for emulating rewrite mod apache:
> http://www.codeplex.com/IIRF
The other question, yes ASPNETDB.MDF in APP_Data is protected normally (it depends on your administrator). To change the path, change the connectionstring.
There are two cases:
If the server is using IIS7 then there is equivalent functionality available using the web.config approach for all files.
If the server is using IIS6 or earlier (and for the time being this is by far the most likely case for shared hosting) then its more of a problem. If you can force all your requests to go via the ASP.NET handler (which normally requires access to the server to configure) then again the web.config approach will work but otherwise you're going to need other tools and a sympathetic hosting provider. For this reason alone one probably wants IIS7...
That said for asp.net there are files that are protected by default anyway - files in app_data as already mentioned plus specific file types (like .config). Additionally one would expect a decent host to provide a directory that is not accessible via the web - ours offer a private and a web folder, both accessible via FTP but only the contents of the latter via the web.
As per the [documentation on Application Folders][1], IIS won't serve requests to content stored in the /app_data folder although your application can read and interact with those files.
ASP.NET recognizes certain folder names that you can use for specific types of content. The following table lists the reserved folder names and the type of files that the folders typically contain.
Note
The content of application folders, except for the App_Themes folder, is not served in response to Web requests, but it can be accessed from application code.