CATPCHA WebPart For SharePoint Blogs Is Done!
Well, kinda. I am pretty much done with it, you can see a screenshot of the comment input replacement below:
(Select For Larger Image)
I finished most of the properties / functionality for this today at a coffee shop today (having ended up breaking mid stream to buy more laptop memory to run VMWare), and am really excited to get this thing out to testers so I can get started on the pieces that are off more interested to me, such as integrating spam providers, assuming that the information that they deliver to me is correct, and that the promises in regards to API keys for their services are true.
Deployment for this is going to be a bitch, I am not going to lie. I have been testing it by replacing the comments listformwebpart (via direct modification of the ONET.xml file) that is used for normal comment injection with mine, which is pretty much the best way for an enterprise deployment since it propagates to all inherited sites. I am currently exploring more elegant options, however the direct editing is easily the most simple method. Obviously, you could just replace that WebPart per SharePoint blog, however this just doesn’t really satisfy the goal that I am shooting for. If you run a SharePoint hosting provider, which providers the blog SiteTemplates, I am particularly interested in deployment options so please do contact me directly.
On the good end, I got rid of the need for the httphandler to be registered in the web.config. Why is an httpmodule used? Well, it is pretty much the best way in order to generate a CAPTCHA image in ASP.NET 2.0. I could have went the ISAPI route but at this point in my life I am entirely too weary to write any more unmanaged code and the httphandler was exceptionally easy to write. There are bunch of different ways that one could go about capturing the GUID of a CAPTCHA image from a cache within a WebPart such as timestamps, etc. however I just went with what seemed to be the standard and used a custom GUID that is generated by the application / handler.
For people using custom httpmodules with SharePoint, this is a tip I found pretty helpful. You don’t actually have to directly edit the web.config file, but rather in the constructor of your WebPart, you can get the configuration of the site that you are programming against, and then manipulate the relevant configuration sections. For example, I was concerned about the httphandlers sections of the web.config file. The first thing that you have to do is to get the current configuration of your SharePoint instance.
- Configuration configuration = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("~");
So the above basically opens your SharePoint web.config, which is great, and allows you to then open the relevant section that you are concerned about.
Then you can register your own handlers at runtime as opposed to actually having to directly edit the web.config. This is obviously very handy when you are targeting organizations that are directly out of your control:
- HttpHandlerAction handler = new HttpHandlerAction(blah)
So you actually don’t have to register the .ashx file per se for the CAPTCHA WebPart to render correctly, which is nice for hosters.
If you own your SharePoint instance (by which I mean you really can do whatever you like with the server) I would really be interested in procuring 15 minutes of your time for testing the WebPart. My gratitude for your contributions will be placed directly into the WebParts assembly properties, and your name will appear directly on sharepointsecurity.com for your time and efforts. Ping me through the contact us page on the sharepointsecurity.com main page, or email me directly at firstname.lastname@example.org if this is something that you can do.