I'm trying to use IIS Dynamic IP Restrictions to throttle requests from the same IP. I have the module running and the requests are nicely throttled if I edit the dynamic restrictions settings from the IIS UI. This is nice however I need to have different rates on different URLs. Login should be for example more strict than static resources. I'm trying to use locations in web.config to achieve this.
<configuration>
<location path="foo">
<system.webServer>
<security>
<dynamicIpSecurity enableLoggingOnlyMode="true">
<denyByRequestRate enabled="true" maxRequests="1"
requestIntervalInMilliseconds="5000" />
</dynamicIpSecurity>
</security>
</system.webServer>
</location>
</configuration>
Unfortunately, this doesn't apply. I'm quite sure it has nothing to do with my app because it doesn't work also on a static web with one HTML file. I'm also quite sure that the location path is correct, because the requests are blocked if I add ...<deny users="*" />.
This is not possible. From the module description:
This module can be configured such that the analysis and blocking
could be done at the Web Server or the Web Site level.
Internally this is implemented as HttpModule (native HttpModule that is). HttpModule runs for every single request - location doesn't affect them. For reference check out
Exclude certain pages from using a HTTPModule
So your only other option (if you need to support this exact module) is to organize your site to several mini-applications instead.
Like
/ -> root web application
/Content -> web application with static content
/Login -> web application with login functionality
And in every single mini-application create web.config with appropriate rules.
Related
I've spent the entire day trying to get this to work, though it seems as if it's meant to be an out-of-the-box functionality for IIS7. I just can't figure what I'm goin wrong.
I want to have a web site (say, the default web site, that's fine) configured for forms authentication. By which I mean to say that regardless how many web applications are configured under this web site, any time an anonymous user tries to access a restricted resource they are sent to the same login page, which gathers their credentials and sends them back to the resource they wanted in the first place.
So I've set the authentication on the web site as follows - basically all off, except: anonymous (which I assume needs to be on so that the unsecured stuff is visible without logging in), and forms authentication. I have forms authentication configured to use a login page within a configured application, so: [default web site\auth\login.aspx]
I have an unsecured application configured, which of course is fine.
I have another application which has some unsecured content at its root ([default web site\test\readme.html]), and another directory where I've added a config file that has the <deny users="?"/> (so, [default web site\test\secure\readme.html]) in a config file. Of course my intention is that an anonymous users try to get resources in this directory they will be redirected to the login page for the whole site.
To my surprise, what happens is this - if I turn off anonymous access for the application I want to secure, rather than sending me to the login page configured at the web site level, I just see an unauthorized message in the browser. If I turn anon on for the secured app then no challenge is ever done and everyone can just see all resources without logging in.
Am I missing something here? Shouldn't web applications configured within a web site all act the same way, and use the sites' authentication scheme? Am I wrong about this being a feature or am I just doing something wrong to make it happen?
I also (after goofing with it for a while) set the login page under the 'Error pages' section of the main web site to handle 401 status, without any luck.
I don't think the asp.net handler is invoked for static files unless you configure it to be. Adding a handlers section for html files in the root config will allow your app using forms authentication to handle html files as well.
<system.web>
<compilation>
<buildProviders>
<add extension=".html" type="System.Web.Compilation.PageBuildProvider" />
</buildProviders>
</compilation>
</system.web>
<system.webServer>
<handlers>
<add name="html" verb="GET, HEAD, POST, DEBUG" path="*.html" type="System.Web.UI.PageHandlerFactory" />
</handlers>
</system.webServer>
According to Ultra-Fast ASP.NET: Chapter 3 - Caching:
Files that the browser retrieves from the server should be stored in
the browser’s cache as long as possible to help minimize server
round-trips.
But how does IIS know what a static content actually is and is not?
Is it just images, CSS, JS and not ASPX, ashx...?
Where can I see in IIS what is already considered to be static and what is not ?
What about the scenario where a page has been declared with <%# OutputCache header (without location)? Are the images, CSS and JS source files inside of it also being output cached with the same properties?
As a best practice, I should set one year into the future as the maximum expiration time. I should use that as the default for all static content on the site
So I did this :
But later, after pressing OK, I can't find any summary menu which shows me: to whom I already put a response header (in this case: the css folder).
Currently, in order to see that css folder has been applied with response headers - I have to go to the css folder again --> Http Response Header-->Set Common Headers --> and then I see it. It isn't written in the web.config.
But if I do it for a file (Login.aspx for example): I do see it in web.config:
<configuration>
<location path="Login.aspx">
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseExpires" cacheControlMaxAge="1.00:00:00" httpExpires="Fri, 15 Feb 2013 00:00:00 GMT" />
</staticContent>
</system.webServer>
</location>
</configuration>
I understand your situation. Sometime its confusing how IIS handles a file. Its also different for IIS 6 vs IIS 7 and different for Classic App Pools and Integrated mode app pools. My experience is mostly with Integrated App Pools on IIS 7.5, so thats the environment I can comment on most accurately.
First Question
But how does IIS knows what is actually a static content and what is
not?
Is it just images , css , js and not ASPX , ashx...?
Where can I see in the IIS what is already considered to be static and
what not ?
You can inspect the list of file handlers in IIS by navigating to your website and then click 'Handler Mappings'. By default these are inherited from the .Net base web.config which is in a different location depending on your .Net framework version.
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\web.config
If a file being requested isn't already explicitly mapped to another handler it falls to a catch all handler (*) as the last option (System.Web.DefaultHttpHandler) which determines if it is a static file or a directory browsing request. So Static files are simply files not bound to another handler already. For example you'll see that *.aspx is already mapped to System.Web.UI.PageHandlerFactory prior to this default handler. So its going to be processed by that handler and not be considered a static file. If you removed that mapping you could technically serve *.aspx as a static file if you really wanted to (just for proof of how it works).
But you can also explicitly list a file type as a static file by adding an entry in your web.config's httpHandlers section mapping the file extensions to System.Web.StaticFileHandler in IIS. For example:
<configuration>
<system.webServer>
<handlers>
<add name="StaticHandler" verb="*" path="*.zip" type="System.Web.StaticFileHandler" preCondition="integratedMode" />
</handlers>
</system.webServer>
</configuration>
This example is using the <system.webServer> config section, so its for an App Pool running in Integrated Mode.
Second Question
What about the scenario where a page has been declared with <%#
OutputCache header(without location) . does the images,css,js src
files inside of it , are also being output cached with the same
properties?
No. Because the page is being server as a separate request (maybe even by a separate handler) it can have totally different cache headers/hints. The host page and the resources it may use are not related from a caching perspective.
In fact you may even want to have a shorter cache period for *.html and a longer cache period for *.jpg or *.png? Something to consider.
Third Question
As a best prcatice , I should set one year into the future as the
maximum expiration time.I should use that as the default for all
static content on the site
Hmm... I might not go as far as one year. How about one month? I would set a global policy like this:
<configuration>
<system.webServer>
<staticContent>
<!-- Set expire headers to 30 days for static content-->
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
</staticContent>
</system.webServer>
</configuration>
This is the same as the sample you showed above, but is not inside a <location> element, instead it is right in the root <configuration> element so it is the default policy. Again this is for an App Pool running in Integrated Mode. Sometimes you also need to turn on:
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<!-- stuff -->
</modules>
</system.webServer>
<system.webServer>
This just makes sure that static files are processed through the managed static file handler which respects the above configuration elements.
Edit to Address Comments
The documentation for the configuration dialog you posted above is located here: Configure the HTTP Expires Response Header (IIS 7)
Apparently these settings are saved in C:\Windows\System32\inetsrv\config\applicationHost.config
I do not have IIS7 and personally develop on IIS 7.5 now. So please post a comment if you can verify this location is accurate!
The static content is the one that IIS is read and send to the browser with out any processing. There you can setup IIS to include some Cache-Control Header to cache it on clients browser computers.
You can do that ether by direct setup IIS, ether by commands on web.config as you say. The commands that you add on web.config and concern the IIS, did not have to do with asp.net it self, but the IIS, and IIS saves his configuration on a different file, so when you change that cache control headers direct on IIS you do not see them on web.config.
Now for the static content like images, CSS, JavaScript, and other similar files they say that you can follow the "never expire" policy by adding 10 years expire.
The issue here is that if you can not change the content of the static file, if for example you cache a javascript file with 10 years, and you make a small change on it, then you need ether to change the file name, ether to add some parameter at the end of it.
Now the <%# OutputCache on a control is referred to the server cache and not to the client, and what is actually do is to cache the render of the control on the server so the next time you ask it to not lose time to renders it again but read it from cache - is still send it to the browser.
And you can also read this answer for some more: What are difference between IIS (Dynamic and Static) cache,OutPutCache and browser cache
How to configure that a web service only be called by one specific web application? Both ones are in the same IIS server.
Framework: 2.0
I think that setting web.config of web service would be enough.
On this example, I'm setting web.config of web service. Web service will be called only by one IP address (127.0.0.1 is IP of IIS Server):
<location path="resources">
<system.webServer>
<security>
<ipSecurity allowUnlisted="false">
<clear/>
<add ipAddress="127.0.0.1"/>
</ipSecurity>
</security>
</system.webServer>
</location>
Would it be ok?
If it's only being called by one specific application on the same server, a Web Service may not be the right choice. It would make more sense for the code to be within a class in the same app. Web services are best suited for situations where multiple apps need to access the same functions.
That said, with IPV6 coming, the option you thought of won't work. If you're really just trying to limit requests to apps that come from the same sever, in you can put the following in code to check to see if it's coming from the local server:
if(Request.IsLocal)
{
//code here
}
For simplicity's sake, you can put the following in Application_BeginRequest in the global.asax file for the web services:
if(!Request.IsLocal)
{
throw new Exception("Only local requests are allowed");
}
This will effectively fend off anything not coming from localhost.
I have a customer of ours that sent out a publication referring to my site but they used the wrong address...they did not provide a page name...it looks like this:
mywebsite.org/Resources/toolkits/bridging
when it should have been
mywebsite.org/Resources/toolkits/bridging/default.aspx
Is there a way to tell ASP.NET to default to this default.aspx when it sees this kind of request or even better, have IIS 7 handle this easily?
This site is live so I would like to avoid having to introduce code if possible.
As per other suggestions, this should be done in the IIS configuration for your website using the IIS Admin tool.
There is however, another alternative - you can add a section in the web.config of your actual ASP.NET application, allowing you to override the IIS configuration right from your application:
<system.webServer>
<defaultDocument>
<files>
<clear />
<!-- Specify each of your files by order of preference here -->
<add value="Default.aspx" />
<add value="Index.aspx" />
<add value="MyOtherPage.aspx" />
</files>
</defaultDocument>
</system.webServer>
The caveat to this though is it may be a little obtuse when the IIS administrator can't figure out why the server configuration isn't working the way he's got it configured. It's not always right to do something just because you can.
Finally, just in case you don't have access to the IIS server or your IIS administrator has reasons for not adding Default.aspx to the default document list in the IIS configuration and for whatever reason, you don't wish to override the IIS configuration in your web.config file, then the quickest and simplest way is to simply create a file called default.asp in that directory containing:
<% Response.Redirect("default.aspx") %>
Default.asp is in the default document list on IIS. The code will automatically redirect the call to the correct page. The downside to this approach though is that there's a performance hit - every time someone calls default.asp - directly or otherwise, the redirect needs to happen which isn't free.
In the Documents tab of the web site properties in IIS you can specify default documents. If you are using .Net2.0 or later on that machine then Default.aspx should already be set....
Default.aspx is not, oddly enough, set as the default document in an IIS installation; In IIS 7, the setting is under "HTTP Features", called "Default Document". Add default.aspx to that list and you should be OK.
If not, you'll need to add a 404 handler that redirects when it sees that URL.
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.