Today I hit the all time record of comment spam with a staggering 367 attacks in just 21 minutes. They were all coming from the same IP address but with various different comments that all had something to do with selling Christmas cards. I don’t mind the occasional comment spam attacks since none get through, but when they hit as hard as they did today I get annoyed because they take up CPU cycles and bandwidth.
I needed a way to block these pesky intruders from leeching on my server and hopefully find a way to keep them from returning.
BlogEngine.NET 1.3 to the rescue
The next version of BlogEngine.NET with the creative title of 1.3, which is due before Christmas, has some new events exposed for extension builders. One of them is called Comment.SpamAttack and gets raised every time a spammer tries to add a comment.
So I wrote a small extension that listens to that event and collects IP addresses from the clients making the spam requests. When the same IP address gets caught spamming comments 3 times, the extension clears the response and sends back a 404 HTTP header. The reason for that is to trick the spammer (which almost always is a dumb robot) to believe that the URL doesn’t exist and therefore it would stop trying and wont come back.
This extension is only a few hours old so I don’t have any statistics on its effect yet, but my spider sense tells me it will have positive effect in fighting the spam attacks right now and in the long term.
You can also create extensions that listens to the Comment.AddingComment which is raised before the comment is saved. That gives you the possibility to do your own spam filtering, because you can then cancel saving the comment and raise the Comment.SpamAttack event by calling the static Comment.OnSpamAttack() method.
I’ll test the extension thoroughly and if it behaves well, it will be included in the 1.3 release. You can also get a sneak peak at the extension by downloading the .cs file below:
BlackLister.zip (886 bytes)
I think by now, most ASP.NET developers have come across some of the different provider models in ASP.NET 2.0. Most likely the Membership, Roles and SiteMap provider but also the custom provider model that you can use to create your own providers.
Still, I often come across custom authentication and authorization mechanisms instead of using the Membership and Roles provider model. Typically, a business object called User has a Logon method that does the authentication and returns a Boolean back to the login page, which sets a cookie and maybe session variable and then redirects the user to the password protected area of the website.
Then there’s usual also some custom authorization mechanism that prevents certain logged in users from certain areas such as admin pages. The menu is custom designed to hide and show only the pages available to the current user and the individual pages also makes the checks.
That is a common scenario and I see it very often. If you have such a scenario on your web application, then consider converting your existing logic to use the provider model. By creating a custom implementation of the Membership, Roles and SiteMap provider, you get all this for free and it is very simple to do so. You can keep your existing code and then build the providers on top of that.
The benefit is that these three providers work together so that the SiteMap automatically shows only the pages a user has permissions to see based on her role. You also get the cookie management for free. But the best part is that you can easily switch to a new provider when needed without changing your existing code. I did that today when I installed BlogEngine.NET on our intranet at ZYB. It had to use the Active Directory Membership provider so that we could log on using our network credentials. It took me 5 minutes to make the transition from my custom XML Membership provider to the Active Directory one. There’s a good guide at MSDN for using the Active Directory provider.
That flexibility comes free of charge with ASP.NET 2.0 and makes the lives of all .NET web developers much easier, more flexible and powerful. I have published my XML Membership provider and will wrap up the XML Roles provider soon and publish it as well.
When you first try the provider model, I promise that you’ll never go back.
Resources