Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We had a major SharePoint outage a few months back because a user wedged their keyboard in such a way as to cause the Enter button to be pressed indefinitely. The user was on a customized people search page and hundreds of POSTs by the same user were submitted asynchronously, which overloaded the server.

Because I work in a large organization, I am looking for a more global way to prevent this from happening.

Is there a way to prevent multiple web form submissions by a common user within a short period of time within IIS?

I am aware we can write javascript to disable the button after it is clicked, but we are hoping to prevent this issue from occurring on other pages where a similar possibility may exist.

Update: It appears looking at the source code, the javascript is performing a document.location = url, whenever keycode 13 (Enter) is pressed. Again, we can write JS to prevent this in this location, but we also want to be able to guard against this kind of issue more generally... preferably at the IIS level.

share|improve this question
Add the JavaScript to every page? – Michael Hampton Oct 29 '12 at 16:32
Thanks for the comment, but unfortunately our SharePoint farm is very large where there are many developers all writing their own custom code. We are hoping for a lower level solution in IIS. – user1209640 Oct 29 '12 at 16:54
Improved user training, then? – Michael Hampton Oct 29 '12 at 16:57
I'm surprised there would not be anything achievable within a web server like IIS, especially since there are many community providers out there serving up ASP.Net to the public internet, and how easy it could be for a developer to write faulty javascript that could inadvertently take down a server. I think the issue I am describing could be akin to an accidental DDOS attack. – user1209640 Oct 31 '12 at 17:26
You would have to find a way to block more than 'x' connections from one IP address. Where x is greater than the amount of simultaneous connections typically used for a standard request with some additional buffer (or likely you'd just triple the number for safety). Likely you would need to use some sort of firewall device between end users and the SharePoint servers... flood protection is what some firewalls call it. – Ashley Steel Nov 1 '12 at 20:52

One option for this would be rate-limiting using something like which can be set to block the offending IP for a set amount of time.

You'd want to baseline the typical requests/second/IP before putting something like this into production, of course, but this should prevent a single user from being able to do something like that again.

share|improve this answer

If the issue is simply avoiding impact due to the number of concurrent requests, there is an add-on for IIS 7, Dynamic IP Restrictions. (This capability is now built-in to IIS8). It's possible to configure this for log-only mode to determine what if any impact there would be before enabling the capability.

  • Seamless integration into IIS 7.0 Manager.
  • Dynamically blocking of requests from IP address based on either of the following criteria:
    • The number of concurrent requests.
    • The number of requests over a period of time.
  • Support for list of IPs that are allowed to bypass Dynamic IP Restriction filtering.
  • Blocking of requests can be configurable at the Web Site or Web Server level.
  • Configurable deny actions allows IT Administrators to specify what response would be returned to the client. The module supports return status codes 403, 404 or closing the connection.
  • Support for IPv6 addresses.
  • Support for web servers behind a proxy or firewall that may modify the client IP address.

Dynamic IP Restrictions in action

Multiple form submits should be addressed at the application level. It's trivially easy to implement with master pages. The following jquery in the master page does the trick for all child content pages:

$("form").submit(function () {
    $(":submit", this).attr("disabled", "disabled");

Another good practice that may be worth adopting: Post/Redirect/Get

share|improve this answer

You can write a global level IIS module and check if same request coming from same user in a specific short time. then you can decide if allow request continue or not.

class CGlobalTestFilterModule:public CGlobalModule
        OnGlobalPreBeginRequest(IN IPreBeginRequestProvider * pProvider)

here is a good guide to implementing IIS modules : you can choose managed modules if you are more familiar with .NET

share|improve this answer
Maybe you can find ready to use module in list of IIS 7 extensions : – hassan.monfared Dec 7 '12 at 17:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.