So now our fit and finish sprint is finished (my PM, Frank, has published the results which demonstrate that, well, fit and finish is never, errr, finished) I’ve been doing some thinking and experimenting. Two things came out of the MVP summit this year, 1) we want logging which isn’t the Enterprise Library and 2) we want to write our own WPL plugins (more specifically a particular Developer Security MVP wanted to write a SQL Injection detector for MySQL).
This week was scheduled to be a lazy week, as we work around planning meetings for sprint 2 so I started experimenting with suitable interfaces and with MEF. MEF is incredibly easy, although having an accent does mean your colleagues give you strange looks when you saying you’re playing with MEF and start recommending drug counselors. Mistaken hearing and the rest of the meth jokes aside I’m thinking of having the following interfaces available for plugins
- IRequestInspector
- IResponseInspector
- IPageInspector
- ILogger
The inspectors would look something like the following;
/// <summary>
/// Defines methods that must be implemented for request inspection.
/// </summary>
public interface IRequestInspector
{
/// <summary>
/// Inspects an HTTP request for potential problems.
/// </summary>
/// <param name="request">The <see cref="HttpRequest"/> to inspect.</param>
/// <returns><c>true</c> if further processing of this request should stop, otherwise <c>false</c>.</returns>
bool Inspect(HttpRequest request);
}
/// <summary>
/// Defines methods that must be implemented for page inspection.
/// </summary>
public interface IPageInspector
{
/// <summary>
/// Inspects an HTTP page for potential problems.
/// </summary>
/// <param name="page">The <see cref="Page"/> to inspect.</param>
/// <returns><c>true</c> if further processing of this page should stop, otherwise <c>false</c>.</returns>
bool Inspect(Page page);
}
/// <summary>
/// Defines methods that must be implemented for response inspection.
/// </summary>
public interface IResponseInspector
{
/// <summary>
/// Inspects an HTTP response's headers for potential problems.
/// </summary>
/// <param name="request">The original <see cref="HttpRequest"/> for this response.</param>
/// <param name="response">A <see cref="HttpResponse"/> to inspect.</param>
/// <returns><c>true</c> if further processing of this response should stop, otherwise <c>false</c>.</returns>
/// <remarks>
/// <para>This method is called at the point in the ASP.NET pipeline where you may still edit response headers
/// via <see cref="HttpResponse.AppendHeader"/>.</para>
/// <para>Accessing the <see cref="HttpResponse.Headers"/> property is only supported with the IIS 7.0 integrated pipeline mode
/// and at least the .NET Framework 3.0. When you try to access the Headers property and either of these two conditions
/// is not met, a PlatformNotSupportedException is thrown.</para>
/// </remarks>
bool InspectHeaders(HttpRequest request, HttpResponse response);
/// <summary>
/// Inspects an HTTP response for potential problems.
/// </summary>
/// <param name="request">The original <see cref="HttpRequest"/> for this response.</param>
/// <param name="response">A <see cref="HttpResponse"/> to inspect.</param>
/// <returns><c>true</c> if further processing of this response should stop, otherwise <c>false</c>.</returns>
bool InspectBody(HttpRequest request, HttpResponse response);
}
Having a single HttpModule for the WPL SRE means I can perform some better caching, centralise the exclusion code and at some point look at parallelising some of the checks via PLinq.
However there are a couple of things I’m dithering about; the first is the interface naming – Inspector does not seem right as they can stop processing of the request or the response or change the request, the response or any ASP.NET WebForms page – but WCF has MessageInspectors which can also stop processing or message with the request or the response. Inspector seems a little passive, Inquisitor seems, well, more amusing. Twitter suggestions including IGatekeeper (or should that be IGateKeeper), ISentinal, IDemiGod (thanks for that Andrew *grin*), ISecurityInspector, IFilter, IIntermediate, IMonitor and carrying on the inquisitor theme, ITorqemada (Andrew again). The other thing I’m mulling over is the return value, should it be true to indicate processing should halt (and an exception thrown) because a problem was found or should it be true to indicate everything is fine and processing should continue.
I am enjoying MEF though – it’s incredibly easy, works in medium trust and means I can support multiple loggers and remove the dependency on the Enterprise Library to boot. It does have a drawback though, I should really compile two versions, one for 3.5 using the CodePlex source for MEF (which is still in beta mode) and one for 4.0 where MEF is built into the framework and thus remove an unnecessary assembly. As I was going to compile a specific 4.0 version of the AntiXSS library to support IHtmlString it’s not much of an extra hardship. Now if I could automate it …
So here’s your first chance to influence the plugin model for WPL – speak now or forever hold your peace :)