问题远没结束

上篇文章提出的问题解决了没有？哦哦，我是指采取命名约定的方式来改变过滤行为。当然有问题，不过我这里提一下比较重要的两个：

首先，就是“改名”这种行为——究竟是否方便？还记得我们的需求吗（提示一下：方便、通用……）？如果采取上面的命名约定方案，我们可能就需要在页面的前端和后端都不断地改名，一会儿加-noffw，一会儿加-json。如果项目只由您来负责这还好办，只是麻烦一些，但是如果您的团队中的前台开发人员性格古怪，固执己见，不愿配合怎么办（打架我喜欢，可惜不能直接解决问题）？再者，假如您除了一个FilterForbiddenWordModule之外还有类似的“FilterScriptInjectionModule”怎么办（别真写这么一个HttpModule，不合适，老赵只是想不出一个恰当的例子了）？如果两个Module都采取命名约定的方式，那么如何制定一个两者能同时认同的约定就也是个麻烦事。

再者，命名真是我们可以控制的吗？某些情况下好说，但是假如您在使用WebForms中的控件怎么办？WebForm中的一个重要特性就是用过Naming Container来避免客户端ID的冲突。假设我们的页面是放在一个Master Page中ID为Main的ContentPlaceHolder中，那么ID为txtPassword的文本框在客户端里生成的HTML便会如下所示——那么我们又能有什么办法可以做到“命名约定”吗？

<input name="ctl00$Main$txtPassword" id="ctl00_Main_txtPassword"></input>

嘿，看来这种命名约定的方式有时候真不是那么通用啊。那么我就来设法解决WebForm这个问题。

其实如果要解决WebForm这个问题，说白了就是要设法可以让服务器端明确指定一些字段的处理方式。这种“特殊”则意味着对于过滤方式的判断必须与特定的Page——泛化一下，HttpHandler进行绑定。这里我先谈一下我的第一个想法：使用Custom Attribute进行标记的方式。我们构造一个FilterForbiddenWordAttribute，其中包含一个抽象GetFilterType方法根据key来指定过滤方式：

public enum FilterForbiddenWordType 
{ 
    Ignored, 
    Normal, 
    Json, 
    Html 
} 
 
public abstract class FilterForbiddenWordAttribute : Attribute 
{ public abstract FilterForbiddenWordType GetFilterType(string key); 
}

我们如果有特别的需求，就可以通过定义一个FilterForbiddenWordHandlerAttribute的子类，重载GetFilterType方法，然后标记在HttpHandler上。如下：

public class DefaultFilterForbiddenWordAttribute : FilterForbiddenWordAttribute 
{ public override FilterForbiddenWordType GetFilterType(string key) 
    { if (key.EndsWith("txtPassword")) 
        { return FilterForbiddenWordType.Ignored; 
        } 
 return FilterForbiddenWordType.Normal; 
    } 
} 
 
[DefaultFilterForbiddenWord] 
public partial class Default : System.Web.UI.Page 
{ 
    ... 
}

当然，我们还需要对FilterForbiddenWordModule进行一些修改才能使之生效（朋友们可以先不要看代码，想想这次改变的关键在哪里？）：

public class FilterForbiddenWordModule : IHttpModule 
{ 
    ... 
 void IHttpModule.Init(HttpApplication context) 
    { 
        context.PostMapRequestHandler += new EventHandler(OnPostMapRequestHandler); 
    } 
 private static void OnPostMapRequestHandler(object sender, EventArgs e) 
    { var context = (sender as HttpApplication).Context; var handlerType = context.Handler.GetType(); var filter = ((FilterForbiddenWordAttribute[])handlerType.GetCustomAttributes( typeof(FilterForbiddenWordAttribute), true)).FirstOrDefault();  
 
        ProcessCollection(context.Request.QueryString, filter); 
        ProcessCollection(context.Request.Form, filter); 
    } 
 private static void ProcessCollection( NameValueCollection collection, FilterForbiddenWordAttribute filter) 
    { var copy = new NameValueCollection(); 
 foreach (string key in collection.AllKeys) 
        { var filterType = (filter == null) ? FilterForbiddenWordType.Normal 
                : filter.GetFilterType(key); 
 Array.ForEach( 
                collection.GetValues(key), 
                v => copy.Add(key, ForbiddenWord.Filter(v, filterType))); 
        } 
 
        ... 
    } 
}

修改示例。例如我们在页面上放置两个文本框txtPassword和txtNormal：

<asp:TextBox ID="txtPassword" runat="server" TextMode="MultiLine" /> 
<asp:TextBox ID="txtNormal" runat="server" TextMode="MultiLine" /> 
<asp:Button ID="Button1" runat="server" Text="Click" />

点击，效果不言而喻：

公布答案：因为我们需要等到确认了HttpHandler类型才能获得FilterForbiddenWordAttribute标记信息，所以这次更新的关键是我们必须推迟进行过滤的时机。推迟到哪个阶段？自然是能够确定HttpHandler类型的最早时机，PostMapRequestHandler。我们通过反射来获取Handler类型上的FilterForbiddenWordAttribute子类的信息，作为Filter传入带有额外参数的ProcessCollection方法中。ProcessCollection方法内部会调用根据filter参数来确定某个key的过滤方式：正常（当作纯文本进行过滤）、忽略（不过滤）、JSON（只过滤JSON内元素的值）以及HTML（忽视tag和attribute，并考虑文字内的HTML Encode）。其余不变。

顺便说一句，以上代码其实只是为了写这些内容而在10分钟内写好的，不考虑性能、缓存、同步、边界等情况——因为我相信看了下面的文字您一定会抛弃这种做法。

继续改进

上面的做法（相对使用命名约定的方式）改进了什么地方？很简单，之前提到的命名约定的缺点就是上述做法的优点：

1. 不同Page（Http Handler）可以自行指定字段所需要的过滤逻辑。

2. 无需前端改名，只需后端标记。

3. 避免复杂的命名约定，使多种横切型的过滤功能可以轻易共存。

真是美妙地嗷嗷的，但是有没有朋友看出问题来？我提示一下：GetFilterType方法中使用了一个常量字符串txtPassword。

估计有朋友会问：“咦，这有什么问题？”粗看似乎没有，不过老赵看到代码中出现常量总是要警惕一番（自觉是个好喜欢）：为啥要是txtPassword而不是txtPassWord（一个常见的拼写错误）？为啥代码中用0而不用-1？这里的问题倒不是说一个常量在代码中到处使用时最好使用一个const——不不，是readonly字段来代替（为啥用const不太好？）。而是……再提示一下，如果某人将页面上的txtName文本框改为txtUserName那会出现何种情况？

嗯嗯，那么Attribute中的GetFilterType方法当然还是在判断一个key是否由txtName结尾，而我们修改后的页面中Post内容中已经变成了txtUserName，咋整？但是可悲的是，我们尊敬的Attribute，就算你拿刀威胁它它也没法知道该替换什么啊。唉，那又有谁才能知道呢？不用多想，当然是页面本身了。

.NET中Custom Attribute的特性深入人心，大大增强了.NET中反射机制的可用性，也因此Kent Beck认为NUnit的设计和使用较JUnit更为优雅。老赵的项目中也到处可见Custom Attribute的存在，写出的代码也简单优美强大地很。不过用多了Custom Attribute也造成了一种思维定势，一些“附加功能”往往都喜欢往上靠，很多问题往往一个功能出来三秒不到脑子里就浮出一个利用Custom Attribute的解决方案。古语有云，“世界如此美好，我却如此浮躁，这样不好，不好……”。事实上ASP.NET框架中已经有了不使用Custom Attribute进行“标记”的现成示例。例如，您知道IRequiresSessionState接口和INamingContainer接口的作用吗？

如果您翻过IRequriedSessionState和INamingContainer接口的文档，就会发现它们有个共同的特点——没有任何成员。这意味着什么呢？这意味着实现了这样的接口的类，唯一的作用就是“别人知道你实现了这个接口”。有点拗口，对吧？其实就是指，这两个接口只起到了标记的作用。使用Custom Attribute或使用接口对一个类进行标记和扩展的优劣取舍，我打算用额外的一篇文章来讨论这个问题（要不现在大家来Brain Storm一下如何？）。目前，朋友们只需关心一点，如果不用Custom Attirubte而使用接口，我们该如何改写上面的程序。并且，这种改变带来了什么好处？

如果在某些情况中，我们也可以把对象本身作为参数传入Custom Attribute的方法中，Attribute方法内部根据参数的属性来实现逻辑，可惜的是，Page类内部的控件成员是protected变量，无法从外部访问。对于我们来说，使Http Handler（即页面）直接实现某个接口的最大（唯一？）好处，就是让该接口的成员可以访问页面内部的非公开成员了。这点就是问题关键，我们现在不必直接使用txtPassword这个常量，而是能够访问页面中的txtPassword控件来获取它相关的属性（ID）。不再赘述，修改如下：

public interface IForbiddenWordFilter 
{ FilterForbiddenWordType GetFilterType(string key); 
} 
 
public partial class Default : System.Web.UI.Page, IForbiddenWordFilter 
{ 
    ... 
 FilterForbiddenWordType IForbiddenWordFilter.GetFilterType(string key) 
    { if (key.EndsWith(this.txtPassword.ID)) return FilterForbiddenWordType.Ignored; return FilterForbiddenWordType.Normal; 
    } 
}

至于HttpModule上的修改，相信不会难道您，老赵就不在这里说帖太多代码浪费带宽了。可以看出，现在的代码中已经没有了txtPassword这个常量，取而代之的是对txtPassword对象ID的访问。现在如果在aspx中修改了这个控件的ID，那么在aspx.cs中的变量也会被重构至对应名字，这大大提高了开发效率，降低了出错可能。

差点忘说了一句，大家千万不要忘了对于WebForms模型，有几个特定的key是不能替换的例如“__VIEWSTATE”和“__VIEWSTATEENCRYPTED”。关于这点，老赵的作法是忽略所有以两条下划线作为开头的Key以保护WebForms模型内部需求。

总结

结合上一篇文章，这似乎就是个较为完整的解决方案，不过这个话题结束了吗？当然没有。在下一篇文章里，我们将讨论几个额外的话题，例如：

• 这个解决方案的适用场合？不适用场合？

• 输入过滤？输出过滤？

• 我们一定要使用HttpModule进行过滤吗？

• 性能？

此外，我想大家在看了这篇文章后来一起思考一些问题，而我对于这些问题的看法也会在下一篇文章中谈到：

• 在WebForms模型中，Page即是一个Handler，于是可以实现IForbiddenWordFilter。那么Page里Control所需要过滤的内容呢？动态加载的Control呢？

• 这篇文章的示例里有个陷阱，您看的出是在哪里吗？

相关文章

• 一个较完整的关键字过滤解决方案（上）

• 一个较完整的关键字过滤解决方案（中）

• 一个较完整的关键字过滤解决方案（下）