我看到在该论坛上很多程序员是从ASP转换到学习ASP.NET上的，所以保留了很多ASP的传统，对ASP.NET提供的更多新特性却没怎么了解过。
关于会员注册登陆系统，其实有心在MSDN上搜索一下，能够找到一些优秀的文章提供给你新的思路。

先说说传统注册登陆系统的实现方法
1、当用户登录时，将用户的标识放在Cookie中来回传送。检测Cookie中的用户标识来决定是否允许访问。
2、当用户登录时，将用户的标识放在Session结构中。检测Session来决定是否允许访问。
3、在要限制访问的页上，利用if语句来判断用户是否有权访问。因为它用的场合很多，许多人将它放在一个单独文件中，用include包含进来实现功能。

那实际上，在ASP.NET中，将上面这种操作进一步提炼封装了。我曾经在这论坛上发表过一篇文章，讲述了在ASP.NET中，怎样充分利用框架所提供的功能来实现注册和登陆，并且比较安全的解决方案，链接如下：http://bbs.bc-cn.net/viewthread.php?tid=67635&star=at#

首先讲一下上面这种方案的原理和优势：
如果你了解过ASP.NET框架的请求模型，你会知道，客户端发出的请求，首先由IIS监听到，IIS根据请求的URI，通过影射提交给aspnet_isapi.dll，它负责启动一个CLR环境来处理用户的请求。
这时请求就在ASP.NET的管道中流动。首先他们会经过一系列的HttpModule模块，当请求流过HttpModule模块后，最终到达HttpHandler处理工厂，在这里，请求页的动态标记被处理，并生成标准的静态HTML标记，然后响应流过HttpModule模块，返回给IIS，IIS就把响应发送到客户端。

ASP.NET在机器级别的配置文件中加载了一些常用的模块，用来执行一些操作，例如基于文件系统授权检查，用户标识检查，引发Begin_Request等事件，因为所有针对页的请求都会流过HttpModule模块，因此可以把它看作在全站高度上执行操作，或者叫做“过滤器”也好。

如果你自己实现了IHttpModule接口的类，也可以在你的站点“应用程序根目录”的web.config配置文件中将其加载进来，你的HttpModule模块就可以处理传入的请求了。在链接的那片贴子中，我们新写的一个HttpModule模块用来赋予用户角色，仅此而已。然后，机器级别的安全检察模块会按照用户所拥有的角色，以及你在Web.config文件中设置的角色访问权限进行比对，从而决定接受或拒绝用户的请求。

那么ASP.NET又是如何标识一个用户的登录呢，实际就底层原理来说，它是发送了一个Cookie来表示用户的。ASP.NET将你传递的用户标识（通常你可以将数据库中的主键值传给它，方便后面的应用），加上创建当时的时间和过期时间（不用Cookie自己的过期时间是因为它会被篡改，不安全），构造一个字符串结构，然后用MD5或SHA签名，并使用DES加密，作为一个Cookie变量发送。DES的密钥由机器级别配置文件提供，每台服务器都不一样（如果要跨站使用就需要配置相同的密钥）。这样ASP.NET通过检测Cookie来识别用户，它的安全性在于：Cookie的内容仅含有用户标识，不含有用户的密码等敏感数据；Cookie的内容经过签名，如果伪造和篡改，ASP.NET不会承认它。虽然DES可以在适当条件下破解，但是得不到更多有用的信息。

在上面的文章中，这一部分ASP.NET为我们封装了几个简单的方法，加入你想精确控制标识的行为，还有更多的方法，可以在MSDN上找到参考。

用户的登录过程，你要做的工作就是到数据库中保存的注册信息中对比用户是合法的，然后告诉ASP.NET即可。
角色授予的过程，你要做的工作也是从你的存储结构中找到用户所拥有的角色，改写用户标识使它含有角色信息。
授权的过程，你要做的工作就是适当配置目录结构中web.config文件中授权配置一节的内容。机器级别的安全授权检查会根据你的配置来决定是否允许用户访问。web.config文件不仅可以针对目录进行配置，也可以针对个别文件进行配置。如果你还要更精确地控制用户行为，Page对象的User属性获取的表识也可以让你在代码中使用。

最后还有一点值得注意，那就是，很多ASP程序员喜欢将用户名和密码都放在Cookie中发送。实际上仅用户名就可以标识用户（因为它是唯一的），密码是冗余数据，并且它是敏感信息，没有必要在Cookie中传递，即便密码是加密过的。另外，我还遇到有些朋友非常乐意开发“自己的加密算法”来加密数据，这种精神是好的，但是“自己的加密算法”可能存在严重的安全问题，经不起验证。所以建议使用现在广泛使用的，甚至收编到国家标准的加密算法为好。

希望这些信息对很多求助于登录注册编程的朋友来说有用