前年我写过一篇随笔抱怨Microsoft在ASP.NET架构中Session_End事件上处理，说来惭愧，其实当年我对ASP.NET运行时的复杂性理解不足。实话说，捕捉通过身份验证和注销身份验证对我来说，意义重大。例如： 在登录前先检查是否已经存在SSO提供器； 登录完成后加载相关的权限，这些加载过程可能与具体应用项目完全无关； 登录结束后通知SSO提供器清除Cookie内容； ...... 目前的ASP.NET提供的解决方案是在Global.CS中加上FormsAuthentication_OnAuthenticated方法来捕捉已通过验证事件。该方法的缺陷是：1.只能捕捉Forms身份验证方式，而不能捕捉Windows和Passport认证方式；2.只能捕捉已通过身份验证事件而不能捕捉身份注销事件；3.必须修改global.cs文件。以上任何一个缺陷都是我无法接受的。当时在ASP.NET1.1解决那个问题时用了五六个接口，十多个类，并且有一个输出类要求应用程序登入和注销时访问相应的方法，而不是自由地使用FormsAuthentication的相关方法。现如今该问题总算比较满意地解决了。思路是这样的：在一个HttpModule中建立两张会话表，一张记录已通过身份验证的会话；另一张记录未通过身份验证的会话，这样，在HttpApplication.AcquireRequestState事件中查找每个会话在这两张表中的状态：状态一 两张表中都没有 这是一个新的会话 状态二 在已通过身份验证的会话表中 已通过身份验证 状态三 在未通过身份验证的会话表中 未通过身份验证 如果是状态一，则立即调用所有SSO提供器的身份查验方法，只要有任何一个SSO提供器证实已经通过了身份验证，则立即将状态调整到状态二，并通知所有订阅身份状态变化的Handler。如果是状态二或状态三，则立即与会话的实际身份状态进行比对。会话实际的身份状态可以通过查询HttpContext.User来获得。如果二者不同，则根据情况调整表中所记录的状态，并向订阅身份变化的Handler发出相应的通知。有一个问题是：会话列表的查询频度非常高，每次Request都不可避免查询一次。所以这里对算法的选择要求较高。我在实际的项目中选择了字符串数组的BinarySearch算法。这样每次添加或删除新的会话时不可避免对字符串在数组中的位置进行调整，以保持排序状态。当然，在比对过程中也需要根据命中率调整比对顺序，例如三种状态中，显然状态二的比例最高(当然数组往往也最庞大)，应该优先选择。最后的解决方案是：只用了三个接口，一个HttpModule和几个内部类就实现了，完全不必修改global.cs，且没有任何输出类供登录认证模块调用，所有的SSO提供器也只需要通过web.config来配置，对业务层是完全透明的。这三个接口是：一个配置参数上下文接口、一个SSO提供器接口(同时兼做捕捉身份状态变化的Handler接口)、一个Handler接口的工厂接口(以保持Handler接口的构造器自由以及决定是否建立Handler接口的实现类实例)。
