ASP.NET构架与安全机制之Http请求处理

导读

在写本系列文章的过程中,我遇到了很大的困惑:在我准备讲述问题A的时候,我发现需要先解释问题B;当我考虑如何讲解问题B的时候,又发现如果对问题C不够清楚,很难较好地理解问题B。好吧,事已至此,我决定从问题C开始着手。不幸的是… 我已经跑题了。

本系列文章原计划分成十个部分讲述Asp.Net构架、安全机制 和 Provider模型,然而在写作的过程中,我发现由于涉及的知识面太广,Provider 模型在本系列文章中的地位已经大大降低了。与此同时,我认识到想用十个Part讲述清楚Asp.Net的构架与安全机制是不可能的,但我仍会尝试用最少的文字讲述最多的内容。

阅读的过程中,你可能会觉得文中有的内容看上去与正在讨论的内容关系不大,这时候请你耐心地读下去,它往往是你理解后面问题的关键。

在开始阅读这一系列文章之前,请注意以下几点:

·本系列文章文会详细讲述 Form验证,粗略讲述Windows验证,不讲述 Passport验证。

·有时候我会采用自顶向下的方式讲述,另一些时候我会采用自底向上的方式讲述,这一切视需要而定。

·尽管我很不愿意在段落之中插入过多的灰色说明文字,但是很多地方不如此很难讲述清楚,我会在所有Part全部发布完后对本系列文章进行修订。

·我们经常提到或者听到三层式开发,也不断在网上搜寻三层式开发的源码来研究。实际上,等你了解了Provider模型后,就会发现最近的三层构架其实就在身边。希望能认真学习Provider模型并思考其实用价值。

·文章中的插图是在 IIS 6.0 和 Windows Server2003 下截取的,如果与 IIS 5.0的区别大到足以产生误导,请反馈给我。

·由于本系列文章涉及的知识点比较多,而我又采用写一个Part发布一个的方式。所以,很可能写Part.4时候才发现Part.3很多地方没有讲清楚,这时候我会停下来重新修改Part.3;我也可能在写Part.5的时候发现Part.1的一些内容挪到Part.2更合适。 请原谅我在做这些改动的时候不再另行通知。

这将是一次漫长的旅途,如果你现在已经整装待发,那我们就上路吧!

引言

我查阅过不少Asp.Net的书籍,发现大多数作者都是站在一个比较高的层次上讲解Asp.Net。他们耐心、细致地告诉你如何一步步拖放控件、设置控件属性、编写CodeBehind代码,以实现某个特定的功能。

这种做法,实际上是回答了“如何去做”的问题,却没有回答“为什么可以这样做”的问题。

尽管我很推崇 悉江华 先生的《圣殿祭祀的Asp.Net开发详解》一书,但当我翻看了一下其对角色(Role) 和 用户(Member)的讲解时,我决定跳过去直接读后面的章节。因为我发现他也随了大流,对这部分的讲解停留在“如何去做”的层面上。我相信像悉先生 这样的牛人是不可能不了解底层运作原理的,仅仅是因为那本书原本就已经很厚了吧。

当你按“如何去做”所讲解的内容去开发程序的时候,对于你的用户,你仍是一名程序员;但对于实现了MembershipProvider 和 RoleProvider 抽象类的微软开发人员来说,你已经成了他们的一个用户。

NOTE:我既不反对一些作者只讲解“如何去做”,也不反对你只学“如何去做”,这样也有它的好处,就是可以快速开发。我只是建议多掌握一点底层知识,对一些问题会有更好的理解。

希望通过这一系列文章的讲解,可以让你更好的理解Asp.Net的安全机制和身份验证及权限管理的底层运作原理。

>

时间: 2024-12-04 19:15:39

ASP.NET构架与安全机制之Http请求处理的相关文章

浅析ASP.NET FORUMS中缓存机制的应用

asp.net|缓存 浅析ASP.NET FORUMS中缓存机制的应用 在ASP.NET中有三种缓存机制,我在这里主要提到的是ASP.NET FORUMS中使用的缓存API Cache对象Cache对象可以说在ASP.NET FORUMS中无所不在,以SiteUrls()类为例在构造函数中有如下代码if (HttpRuntime.Cache[cacheKey] == null) { . .System.Web.Caching.CacheDependency dep = new System.We

ASP.NET MVC的路由机制:命名路由

首先看一下命名路由和没有命名的差别: 命名路由: routes.MapRoute( name: "Test", // Route name url: "code/p/{action}/{id}", // URL with parameters defaults: new { controller = "Section", action = "Index", id = UrlParameter.Optional } // Par

通过扩展改善ASP.NET MVC的验证机制[使用篇]

原文:通过扩展改善ASP.NET MVC的验证机制[使用篇] ASP.NET MVC提供一种基于元数据的验证方式是我们可以将相应的验证特性应用到作为Model实体的类型或者属性/字段上,但是这依然具有很多的不足.在这篇文章中,我结合EntLib的VAB(Validation Application Block)的一些思想通过扩展为ASP.NET MVC提供一种更为完善的验证机制.[源代码从这里下载] 目录: 一.扩展旨在解决怎样的验证问题 二.一个简单的消息维护组件 三.多语言的支持 四.基于某

ASP.NET的错误处理机制

对于一个Web应用程序来说,出错是在所难免的,因此我们应该未雨绸缪,为可能出现的错误提供恰当的处理.事实上,良好的错误处理机制正是衡量Web应用程序好坏的一个重要标准.试想一下,当用户不小心在浏览器输入了错误的URL或者当用户提供了一些信息导致程序出错的时候,如果我们没有对这些情况进行处理,而是任由404或是500的错误页面甚至出错的堆栈信息呈现在用户面前,这无疑会把一些用户给吓跑.所以,在我们开发Web应用程序的时候,应该对错误处理机制有充分的了解. 让我们回到ASP.NET上来,先提两个问题

ASP.NET MVC的运行机制

一.ASP.NET + MVC IIS与ASP.NET管道 MVC.MVP以及Model2[上篇] MVC.MVP以及Model2[下篇] ASP.NET MVC是如何运行的[1]: 建立在"伪"MVC框架上的Web应用 ASP.NET MVC是如何运行的[2]: URL路由 ASP.NET MVC是如何运行的[3]: Controller的激活 ASP.NET MVC是如何运行的[4]: Action的执行 二.URL 路由 ASP.NET的路由系统:URL与物理文件的分离 ASP.

深入剖析ASP.NET 2.0缓冲机制

缓冲功能是开发人员构建ASP.NET 2.0 Web应用程序的重要关注点之一.本文试图通过三个示例页面全面剖析ASP.NET 2.0提供的新的缓冲机制. 一.简介 ASP.NET 1.x Cache API是一种革命性特征.当一个XML文件或另一个缓冲项的内容改变时,Cache API提供了诸如声明性输出缓冲.以编程方式控制输出缓冲以及使缓冲项无效等能力.尽管这大大改进了Web应用程序的性能,但遗憾的是,ASP.NET 1.x并没有提供一种机制来实现当数据库中的数据改变时使一个缓存对象中的数据无

Asp.Net Mvc: Model Binding 机制分析

环境: Windows 2008, VS 2008 SP1, Asp.Net Mvc RC1 请求过程片段: 在请求的Action被调用之前,ControllerActionInvoker.InvokeAction()方法被调用,在这个方法里 面,有一个ReflectedActionDescriptor的实例会被构建,这个实例包含Action的描述信息. 接着,ControllerActionInvoker.GetParameterValues()方法被调用,通过传入的之前创建的 Reflect

深度解析ASP.NET中的Callback机制

看到不少朋友最近在写使用callback的文章,也有点手痒,也来涂鸦一下,挖掘挖掘callback的潜力.callback的一般使用方法还算简单,直接参照msdn的帮助和范例就足够了.但是想要真正用好.用精,或者想开发一些基于callback机制的WEB组件,那么,就要先深入了解callback的实现机制了.在本文中,Teddy将和您一起解析callback的整个调用.反馈机制,相信对于帮助您更好的使用callback,将能有一定的益处. Callback vs ASP.NET AJAX 首先,

通过扩展改善ASP.NET MVC的验证机制[实现篇]

在<使用篇>中我们谈到扩展的验证编程方式,并且演示了本解决方案的三大特性:消息提供机制的分离.多语言的支持和多验证规则的支持,我们现在来看看这样的验证解决方案最终是如何实现的. 目录: 一.为验证创建一个上下文:ValidatorContext 二.通过自定义ActionInvoker在进行操作执行之前初始化上下文 三.为Validator创建基类:ValidatorBaseAttribute 四.通过自定义ModelValidatorProvider在验证之前将不匹配Validator移除