关闭

ASP.NET的身份验证

161人阅读 评论(0) 收藏 举报

ASP.NET的身份验证分两种形式:“Windows身份验证”与“Forms身份验证”。其实可以这样粗略的理解验证过程:

 

 

所谓ASP.NET的“Windows身份验证”方式,其实就是ASP.NET自身并不对请求做任何身份验证,所有通过IIS验证的请求将直接获得资源。

ASP.NET的“Forms身份验证”是指对通过IIS验证的请求,编写代码提取请求中的身份信息,并与合法的身份信息集合比对,如能找到匹配,则验证通过,否则不通过。在这里,请求中的身份信息来源于用户在网页中的表单内的输入,因此而得名。

关键代码分析:

FormsAuthentication..::.Authenticate 方法:

public static bool Authenticate(

         string name,

         string password

)

MSDN对此方法的解释:“对照存储在应用程序配置文件中的凭据来验证用户名和密码。”。对此我相当困惑,难道ASP.NET认为所有的用户信息应该保存在配置文件中?那如果需要添加或删除用户就应该编写程序读取和修改配置文件,对吗?如果有成百上千个用户,那将会是一个相当壮观的配置文件了。结论:这是一个没有价值的方法。实际上用户信息总是保存在数据库中(而不是配置文件中),需要另外编写代码通过访问数据库来验证身份合法性。

FormsAuthentication..::.RedirectFromLoginPage 方法的一个重载:

public static void RedirectFromLoginPage(

         string userName,

         bool createPersistentCookie,

         string strCookiePath

)

MSDN对此方法的解释:“使用 Forms 身份验证 Cookie 的指定 Cookie 路径,将经过身份验证的用户重定向回最初请求的 URL 或默认 URL。”。实际上这个方法相当关键,除了重定向外,它还有两个重要处理:

1、  它认可了身份信息;

2、  它缓存了身份信息

在这个方法被执行后,在Cookie有效的范围内:

1、  对应用程序(或简言之“网站”)的所有资源请求都被ASP.NET认为合法;

2、  任何时候可以通过“Context.User.Identity.Name”属性访问当前用户名。

谈到这里暂且按下不表,让我们看看身份验证与权限判断的关系先。事物总是不断发展的,而且越来越复杂。如果一个身份经过了验证就可以访问应用的全部资源,这样很可怕。权限判断这样限制:对通过验证的身份,根据权限设定有选择的提供部分资源。权限设定信息与合法用户信息一样存储于数据库中。

总结一下,我们看到了这样一些事实:

1、  要求用户输入用户名与密码的身份验证(称之为“表单身份验证”)需要访问特定的数据库,这种技术需求很难由ASP.NET直接满足;

2、  权限设定信息与合法用户信息在数据库中联系非常密切。

所以在实战中往往会抛开ASP.NET的“Forms身份验证”(换言之,这只是某软强卖给开发人员的鸡肋),而完全由自己开发“表单身份验证”与“权限判断”。

    身份验证实现首先面临的核心问题是“将当前身份信息保存在哪里?”。一个严肃的系统设计员会仔细的思考并慎重的决定。下面给出笔者对SessionCookie的选择指导:

1、  企业级的应用(满足企业业务需求,部署于企业内部网络中)由于处理的是敏感的业务问题并且机器暴露在办公室内,所以安全性要求很高,往往采用Session保存用户信息。当用户关闭浏览器时,Session中的信息会全部丢弃。

2、  商业网站(部署于互联网上,比如某某论坛)由于家庭用户使用居多,往往采用Cookie保存用户信息。当用户关闭浏览器后,一段时间内再次浏览网站不用重复输入用户信息。

3、  如果是涉及单点登录的大型应用,要求用一次登录访问多个应用,恕我才拙,留给读者自己思考吧。

    这文章的目的在于解读ASP.NET的身份验证技术,使初学者可以少走一些弯路,不要在一些没有价值的地方消耗过多的时间。一句话总结:抛开ASP.NET的“Forms身份验证”。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3309次
    • 积分:49
    • 等级:
    • 排名:千里之外
    • 原创:2篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条
    文章存档
    阅读排行