引言
前一段时间有两个朋友问我，为什么在HttpModule中无法获得到Session值，因为他们希望自定义一个 HttpModule，然后在其中获取Session来进行用户验证。我奇怪为什么不使用.Net Framework已经提供的 验证机制，而要和Asp时一样，自己手工进行cookie+Session验证？我们是基于.Net Framework这个平台 进行编程，所以我觉得，在很多情况下，使用Framework已经建立好的机制会显著地提高工作效率，而 且.NET Framework内置的验证机制通常也更加安全。
.Net提供了一整套的验证和授权机制，这里验证和授权是不同的概念，验证（Authentication）是指 “证明你确实是你所说的人”，通常是提供一个用户名和口令，然后与持久存储(比如数据库)中的用户名 和口令进行对比。授权（Authorization）是指“你是否有足够的权限做某件事”，此时你的身份已经被 证明过了（匿名用户、会员还是管理员），授权通常与用户组或者用户级别联系起来，不同的用户组拥有 不同的权限（访问特定页面或者执行特定操作）。
回想一下我刚接触.Net时，也曾经完全绕过.NET的验证，自己编码采用Cookie+Session实现身份验证 ，并且一个Asp.Net 登录控件都没有使用，那时候的理由是：我要使用自定义的用户表，不能使用 Asp.Net安全机制在App_Data下自动生成的AspNetDB.mdf中的一系列数据表。除此以外，还有一个原因， 就是.Net验证机制的核心IPrincipal和Identity提供的信息用户信息太少了，当在页面后置代码中使用继 承来的User属性（IPrincipal类型）时，它的Identity属性只有一个Name与用户数据相关 (AuthenticationType与IsAuthenticated都是与验证相关)，而很多时候我们都需要许多额外的用户数据 。其实这只是一个误解罢了，以为使用Asp.Net的验证机制和登录控件就一定要使用其附带的数据表，以 为Identity就只能携带一个Name属性。
实际上，.NET的安全机制包括了几个部分，除了验证以外，还包括MemberShip、Profile、Role等，我 们完全可以只使用它的验证机制，而绕过它的MemberShip、Profile和Role，来实现通常我们用 Cookie+Session完成的功能，而且更高效更安全。这篇文章将快速地实现这样的一个流程。
开始前的准备
创建页面，配置Web.config
我们先创建解决方案、建立站点，然后在站点中添加下述文件，它们将会在后面使用：
