Asp.net的应用程序对象和页面生存周期

2024-10-09 12:53:17

IIS在接到一个新的http请求后，最终会调用asp.net_isapi.dll的 ISAPI扩展(特指IIS6.0环境，iis7.0的应用程序池默认为集成方式，相对有所变化)，然后传递到httpRuntime Pipe(http运行时管道)，Asp.Net这时才开始运行(即HttpRunTime是Asp.Net真正的入口)，HttpRunTime会为每个asp.net应用自动创建一个HttpApplication的实例，而该实例中又包含以下属性:

注1

Application -->相当于传统意义上asp时代的application对象，通常用于定义一个asp.net应用的全局变量

Context -->HttpContext(上下文)类的实例【Asp.Net新增的】

Modules -->影响当前应用程序的HttpModule模块集合

Request -->类似于asp中的Request对象，通常用于接收一些特定的值(比如Request.Form或Request.QueryString)

Response -->类似于asp中的Response对象，通常用于向做页面输出指定内容(比如Resonse.Write)

Server -->类似于asp中的Server对象，通过它能获得一些服务端的信息(比如Server.MapPath)

Session -->类似于asp中的Session对象

User -->用于获取用户认证相关的安全信息

从上面的属性可以发现：很多其实在asp年代已在使用，只有Context,Modules,User这三个是Asp.Net新增的

HttpApplication类除了具备"注1"的几个属性外，还有自己的方法，这里特别提一下Init方法和Dispose方法，这二个方法均可重载.

它们的调用时机为:

Init方法在Application_Start之后调用，而Dispose在Application_End之前调用，另外 Application_Start在整个asp.net应用的生命周期内只激发一次(比如IIS启动或网站启动时)，类似的 Application_End也只有当asp.net应用程序关闭时被调用(比如IIS停止或网站停止时)

除了Application_Start和Application_End方法，HttpApplication还提供了以下事件:

这些事件包括前面提到的可重载的Init及Dispose方法，再加上Session对应的Session_Start与Session_End方法，均可直接在Global.ascx.cs中以Application_XXX的形式使用(因为Global.ascx.cs中定义的类Global本身就是继承自HttpApplication的)

代码如下:

public class Global : System.Web.HttpApplication

再来看一下相对asp而言，新增的Context,Modules,User这三个属性

Context：

Context即HttpContext类的实例，在几乎整个aspx页面生命周期中，Context上下文一直伴随着各个环节向下传递

所以我们几乎可以在web应用中的任何环节，用HttpContext.Current来引用到当前的上下文实例，从HttpContext的定义上，还可以发现Context本身的属性中，又可以得到 Application,ApplicationInstance,Profile,Response.Request...等对象的实例引用

回想一下：

代码如下:

public class Handler1 : IHttpHandler
{

public void ProcessRequest(HttpContext context)
        {
            context.Response.ContentType = "text/plain";
            context.Response.Write("Hello World");
        }

public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }

我们在使用一个ashx文件时，ProcessRequest方法便是把当前上下文传递进来，进而通过context得到Response对象的引用，最终可以向页面输出任何想要的内容.

Modules:

每一个实现了IHttpModule接口的类，就可以被认为是Http模块组件，可以理解为http请求拦截器，拦截到http请求后，它能修改正在被处理的Context上下文，完事儿之后，再把控制权交还给管道，如果还有其它模块，则依次继续处理，直到所有Modules集合中的 HttpModule都“爽”完为止(注：可怜的http请求就这样给各个httpModule轮X了)

asp.net2.0默认内置了很多HttpModule，从Machine.Config文件中可以发现以下默认的内置模块:

注2
AnonymouseIdentification --为匿名用户分配一个临时身份
FileAuthorization --验证用户是否有请求文件的Windows NT许可
FormsAuthentication --窗体身份验证模块(如果没有这个模块,asp.net就无法以用户名/密码[即FOrms]方式验证)
OutputCache --输出缓存模块
PassportAuthentication --PassPort验证模块
Profile --用户配置模块(如果没有它，asp.net中就无法使用Profile)
RoleManager --角色管理
SessionSate --会话状态模块
UrlAuthorization --基于URL的身份验证模块
WindowsAuthentication --Windows和IIS身份验证模块

User：

如果您使用过asp.net2.0内置的Membership/Role机制来进行访问认证，就会对User对象感到很熟悉，比如：

代码如下:

if (HttpContext.Current.User.Identity.IsAuthenticated)
{
//用户登录过了...
}

我们常用它来判断当前浏览用户的登录状态，关于User类的更详细定义，可参见MSDN

生命周期：

最后再来回顾一下Asp.Net中Page页的生命周期，Page中定义了几个事件:

总体上讲：一个ASPX页面被请求时，最终的生命周期就是由Page中定义的上述事件(还有一些可重载的回调方法)以及以前提到的HttpApplication类中定义的事件(以相应的回调方法)共同触发或调用，最终叠加形成的一连串处理过程。

如果先不考虑HttpApplication中的事件处理方法(即不考虑我们在Global.ascx.cs中定义的Application_XXX处理方法)，Page中的事件(方法)常规触发(调用)顺序为：

01.Page_PreInit

02.Page_Init

03.Page_InitComplete

04.Page_PreLoad

05.Page_Load

06.Page_LoadComplete

07.Page_PreRender

08.Page_SaveStateComplete

09.Page_Unload

这是在Page页面未回发，且不考虑页面子控件的前提下正常的顺序，如果加入页面回发(比如在页面中放一个asp:Button，然后在Button的Click回发事件中加入处理函数)后，顺序稍微有些变化：

01.Page_PreInit

02.Page_Init

03.Page_InitComplete

04.Page_PreLoad

05.Page_Load

06.Button1_Click

07.Page_LoadComplete

08.Page_PreRender

09.Page_SaveStateComplete

10.Page_Unload

不同的地方在于：回发事件Button1_Click在Page_Load后被触发.

最后再把HttpApplication的事件考虑进来，看下叠加后的顺序，不过先别着急，我们先来看一种特殊情况，如果一个asp.net应用根目录下未设置默认页，这时直接浏览根目录，比如http://localhost:2345/ 时，Globl.ascx.cs中定义的Application_XXX方法的调用顺序如下：
2010-03-28 15:01:39 413 Application_Start

2010-03-28 15:01:39 491 Init

2010-03-28 15:01:39 491 Application_BeginRequest

2010-03-28 15:01:39 506 Application_AuthenticateRequest

2010-03-28 15:01:39 506 Application_PostAuthenticateRequest

2010-03-28 15:01:39 506 Application_AuthorizeRequest

2010-03-28 15:01:39 522 Application_PostAuthorizeRequest

2010-03-28 15:01:39 522 Application_ResolveRequestCache

2010-03-28 15:01:39 522 Application_PostResolveRequestCache

2010-03-28 15:01:39 522 Application_PostMapRequestHandler

2010-03-28 15:01:39 522 Application_AcquireRequestState

2010-03-28 15:01:39 537 Application_PostAcquireRequestState

2010-03-28 15:01:39 537 Application_PreRequestHandlerExecute

2010-03-28 15:01:39 553 Application_Error

2010-03-28 15:01:39 553 Application_EndRequest

2010-03-28 15:01:39 569 Application_PreSendRequestHeaders

2010-03-28 15:01:39 569 Application_PreSendRequestContent

可以看到会触发Application_Error事件，即HttpRuntime认为这是一个错误.

紧接着再浏览一个实际存在的页面，如果这时应用程序有严重错误，导致Application关闭(比如web.config配置错误)，调用的顺序如下:
2010-03-28 15:03:47 704 Application_BeginRequest

2010-03-28 15:03:47 704 Application_AuthenticateRequest

2010-03-28 15:03:47 766 Application_PostAuthenticateRequest

2010-03-28 15:03:47 766 Application_AuthorizeRequest

2010-03-28 15:03:47 766 Application_PostAuthorizeRequest

2010-03-28 15:03:47 766 Application_ResolveRequestCache

2010-03-28 15:03:47 783 Application_PostResolveRequestCache

2010-03-28 15:03:48 667 Application_PostMapRequestHandler

2010-03-28 15:03:48 667 Application_AcquireRequestState

2010-03-28 15:03:48 683 Application_PostAcquireRequestState

2010-03-28 15:03:48 698 Application_PreRequestHandlerExecute

2010-03-28 15:03:48 745 Page_PreInit

2010-03-28 15:04:02 903 Page_Unload

2010-03-28 15:04:02 903 Application_Error

2010-03-28 15:04:02 918 Application_EndRequest

2010-03-28 15:04:02 996 Application_PreSendRequestHeaders

2010-03-28 15:04:02 996 Application_PreSendRequestContent

2010-03-28 15:04:03 371 Application_Disposed

2010-03-28 15:04:03 371 Dispose

2010-03-28 15:04:03 386 Application_End

对比刚才的顺序，会发现Application_Start及Init没有再次被调用，也印证了文章前面提到的一些结论 (Application_Start在整个asp.net应用生命周期内只触发一次)，而且从最后的三个输出能知道：应用程序关闭时 Application_Disposed,Dispose,Application_End按顺序调用.

再"重新"浏览(指web Server重启)一下正常访问的页面，在不出错也不回发的情况下，顺序如下:
2010-03-28 15:08:11 513 Application_Start

2010-03-28 15:08:11 591 Init

2010-03-28 15:08:11 591 Application_BeginRequest

2010-03-28 15:08:11 591 Application_AuthenticateRequest

2010-03-28 15:08:11 591 Application_PostAuthenticateRequest

2010-03-28 15:08:11 606 Application_AuthorizeRequest

2010-03-28 15:08:11 606 Application_PostAuthorizeRequest

2010-03-28 15:08:11 606 Application_ResolveRequestCache

2010-03-28 15:08:11 606 Application_PostResolveRequestCache

2010-03-28 15:08:11 622 Application_PostMapRequestHandler

2010-03-28 15:08:11 637 Application_EndRequest

2010-03-28 15:08:11 637 Application_PreSendRequestHeaders

2010-03-28 15:08:11 637 Application_PreSendRequestContent

2010-03-28 15:08:11 637 Application_BeginRequest

2010-03-28 15:08:11 637 Application_AuthenticateRequest

2010-03-28 15:08:11 653 Application_PostAuthenticateRequest

2010-03-28 15:08:11 653 Application_AuthorizeRequest

2010-03-28 15:08:11 653 Application_PostAuthorizeRequest

2010-03-28 15:08:11 653 Application_ResolveRequestCache

2010-03-28 15:08:11 653 Application_PostResolveRequestCache

2010-03-28 15:08:11 653 Application_PostMapRequestHandler

2010-03-28 15:08:11 653 Session_Start

2010-03-28 15:08:11 653 Application_AcquireRequestState

2010-03-28 15:08:11 653 Application_PostAcquireRequestState

2010-03-28 15:08:11 653 Application_PreRequestHandlerExecute

2010-03-28 15:08:11 669 Page_PreInit

2010-03-28 15:08:11 684 Page_Init

2010-03-28 15:08:11 684 Page_InitComplete

2010-03-28 15:08:11 684 Page_PreLoad

2010-03-28 15:08:11 684 Page_Load

2010-03-28 15:08:11 684 Page_LoadComplete

2010-03-28 15:08:11 684 Page_PreRender

2010-03-28 15:08:11 684 Page_SaveStateComplete

2010-03-28 15:08:11 700 Page_Unload

2010-03-28 15:08:11 700 Application_PostRequestHandlerExecute

2010-03-28 15:08:11 700 Application_ReleaseRequestState

2010-03-28 15:08:11 700 Application_PostReleaseRequestState

2010-03-28 15:08:11 700 Application_UpdateRequestCache

2010-03-28 15:08:11 700 Application_PostUpdateRequestCache

2010-03-28 15:08:11 700 Application_EndRequest

2010-03-28 15:08:11 700 Application_PreSendRequestHeaders

2010-03-28 15:08:11 700 Application_PreSendRequestContent

2010-03-28 15:08:11 793 Application_BeginRequest

2010-03-28 15:08:11 793 Application_AuthenticateRequest

2010-03-28 15:08:11 793 Application_PostAuthenticateRequest

2010-03-28 15:08:11 793 Application_AuthorizeRequest

2010-03-28 15:08:11 793 Application_PostAuthorizeRequest

2010-03-28 15:08:11 793 Application_ResolveRequestCache

2010-03-28 15:08:11 793 Application_PostResolveRequestCache

2010-03-28 15:08:11 809 Application_PostMapRequestHandler

2010-03-28 15:08:11 809 Application_AcquireRequestState

2010-03-28 15:08:11 809 Application_PostAcquireRequestState

2010-03-28 15:08:11 809 Application_PreRequestHandlerExecute

2010-03-28 15:08:11 825 Application_PostRequestHandlerExecute

2010-03-28 15:08:11 825 Application_ReleaseRequestState

2010-03-28 15:08:11 840 Application_PostReleaseRequestState

2010-03-28 15:08:11 949 Application_UpdateRequestCache

2010-03-28 15:08:11 949 Application_PostUpdateRequestCache

2010-03-28 15:08:11 965 Application_EndRequest

2010-03-28 15:08:11 981 Application_PreSendRequestHeaders

2010-03-28 15:08:11 981 Application_PreSendRequestContent

哇！原来一个页面访问下来，会调用到这么多的方法，怪不得很多高并发的大型网站，通常都要自己写一个精减的HttpHandler用来取代Page做为基类，以期望获得更好的性能

最后：我们在做网站开发时，不可能只用到Page页，很多时候还会用到UserControl（用户自定义控件），先看下它的继承关系，比如我们创建了一个TestUserControl的用户控件

TestUserControl --> UserControl ---> TemplateControl --> Control

最终在Control类的定义下，可以看到

这似乎表明用户控件中，应该有Page_Init,Page_Load,Page_Unload...等事件，通常我们只用到Init,Load事件，如果加入一个用户控件后，整个生命周期就更复杂了：

2010-06-12 15:35:28 042 Application_Start

2010-06-12 15:35:28 072 Init

2010-06-12 15:35:28 072 Application_BeginRequest

2010-06-12 15:35:28 082 Application_AuthenticateRequest

2010-06-12 15:35:28 082 Application_PostAuthenticateRequest

2010-06-12 15:35:28 092 Application_AuthorizeRequest

2010-06-12 15:35:28 102 Application_PostAuthorizeRequest

2010-06-12 15:35:28 102 Application_ResolveRequestCache

2010-06-12 15:35:28 112 Application_PostResolveRequestCache

2010-06-12 15:35:28 122 Application_PostMapRequestHandler

2010-06-12 15:35:28 142 Application_EndRequest

2010-06-12 15:35:28 142 Application_PreSendRequestHeaders

2010-06-12 15:35:28 142 Application_PreSendRequestContent

2010-06-12 15:35:28 152 Application_BeginRequest

2010-06-12 15:35:28 152 Application_AuthenticateRequest

2010-06-12 15:35:28 162 Application_PostAuthenticateRequest

2010-06-12 15:35:28 162 Application_AuthorizeRequest

2010-06-12 15:35:28 162 Application_PostAuthorizeRequest

2010-06-12 15:35:28 172 Application_ResolveRequestCache

2010-06-12 15:35:28 172 Application_PostResolveRequestCache

2010-06-12 15:35:28 172 Application_PostMapRequestHandler

2010-06-12 15:35:28 172 Session_Start

2010-06-12 15:35:28 172 Application_AcquireRequestState

2010-06-12 15:35:28 182 Application_PostAcquireRequestState

2010-06-12 15:35:28 182 Application_PreRequestHandlerExecute

2010-06-12 15:35:28 192 Page_PreInit

2010-06-12 15:35:28 192 TestUserControl.Page_Init

2010-06-12 15:35:28 202 Page_Init

2010-06-12 15:35:28 202 TestUserControl.TestProperty.Set

2010-06-12 15:35:28 202 Page_InitComplete

2010-06-12 15:35:28 202 Page_PreLoad

2010-06-12 15:35:28 202 Page_Load

2010-06-12 15:35:28 202 TestUserControl.Page_Load

2010-06-12 15:35:28 202 TestUserControl.ShowData()

2010-06-12 15:35:28 212 TestUserControl.Repeater1.ItemDataBound()

2010-06-12 15:35:28 222 TestUserControl.Repeater1.ItemDataBound()

2010-06-12 15:35:28 232 TestUserControl.Repeater1.ItemDataBound()

2010-06-12 15:35:28 232 Page_LoadComplete

2010-06-12 15:35:28 232 Page_PreRender

2010-06-12 15:35:28 232 TestUserControl.Page_PreRender

2010-06-12 15:35:28 242 Page_SaveStateComplete

2010-06-12 15:35:28 242 TestUserControl.Page_Unload

2010-06-12 15:35:28 252 Page_Unload

2010-06-12 15:35:28 252 Application_PostRequestHandlerExecute

2010-06-12 15:35:28 252 Application_ReleaseRequestState

2010-06-12 15:35:28 252 Application_PostReleaseRequestState

2010-06-12 15:35:28 262 Application_UpdateRequestCache

2010-06-12 15:35:28 262 Application_PostUpdateRequestCache

2010-06-12 15:35:28 262 Application_EndRequest

2010-06-12 15:35:28 272 Application_PreSendRequestHeaders

2010-06-12 15:35:28 272 Application_PreSendRequestContent

2010-06-12 15:35:28 282 Application_BeginRequest

2010-06-12 15:35:28 292 Application_AuthenticateRequest

2010-06-12 15:35:28 292 Application_PostAuthenticateRequest

2010-06-12 15:35:28 302 Application_AuthorizeRequest

2010-06-12 15:35:28 302 Application_PostAuthorizeRequest

2010-06-12 15:35:28 302 Application_ResolveRequestCache

2010-06-12 15:35:28 312 Application_PostResolveRequestCache

2010-06-12 15:35:28 312 Application_PostMapRequestHandler

2010-06-12 15:35:28 322 Application_AcquireRequestState

2010-06-12 15:35:28 322 Application_PostAcquireRequestState

2010-06-12 15:35:28 322 Application_PreRequestHandlerExecute

2010-06-12 15:35:28 332 Application_PostRequestHandlerExecute

2010-06-12 15:35:28 332 Application_ReleaseRequestState

2010-06-12 15:35:28 332 Application_PostReleaseRequestState

2010-06-12 15:35:28 342 Application_UpdateRequestCache

2010-06-12 15:35:28 342 Application_PostUpdateRequestCache

2010-06-12 15:35:28 342 Application_EndRequest

2010-06-12 15:35:28 342 Application_PreSendRequestHeaders

2010-06-12 15:35:28 342 Application_PreSendRequestContent

2010-06-12 15:36:40 034 Session_End

验证一个ASP.NET应用程序和页面的生命周期的实现代码

如果我们能更好地掌握这样一个过程,那么对单个ASP.NET Page的生命周期也能更好地了解: 下面介绍如何编写一个简单的ASP.NET 页面和一个简单的HttpModule,对MSDN里提到的ASP.NET的生命周期进行验证 1. 首先使用Visual Studio 2010建立一个空的ASP.NET网站 (ASP.NET 4.0) 2. 添加一个Default.aspx,添加三个ASP.NET控件,分别为TextBox,Button和Validator: 复制代码代码如下: <form i
ASP.NET MVC4之js css文件合并功能(3)

MVC4增加了一些新功能,接下来,我们来研究下MVC4中的新增功能,我们在新建一个MVC4项目的时候,会发现在项目下多出了一个App_Start文件夹,文件夹下面有4个文件,BundleConfig.cs,FilterConfig.cs,RouteConfig.cs,WebApiConfig.cs,其中BundleConfig.cs文件就是我们这一节要讲的的文件. 众所周知,浏览器在向服务器发送请求的时候,请求的文件连接数量是有限制的.使用BundleConfig可以将多个文件请求和并成一个请求
调试ASP.NET应用程序的方法和技巧

以前使用ASP开发过Web应用程序的人员肯定知道调试Web应用程序是多么麻烦.在ASP中,调试是痛苦的,通常包括了使用Response.Write()方法输出变量的值.那么请问一下自己:你有多少次忘记了在布署应用程序之前删除了调试语句? 随着.NET框架组件的出现这种情况发生了彻底的改变.在.NET中,你可以使用Visual Studio .NET中的调试程序跟踪整个Web应用程序的执行,或者使用System.Web.TraceContext名字空间中的Trace类.本文演示如何使用Trace类
ASP.NET中日历控件和JS版日历控件的使用方法（第5节）

今天小编带大家以做任务的形式了解ASP.NET中日历控件的使用方法,主要任务内容: 1.添加一个日历,设置日期以蓝色的完整名称显示,周末以黄色背景红色文字显示,而当前日期使用绿色背景显示,用户可以选择一天.一周或整个月,被选的天/周/月使用灰色背景色来显示.当选中一个日期后,把时间显示在下面的一个文本框中,效果如图所示: 2.设计一个注册页面,使用js日历控件帮助用户输入出生日期.效果如图所示: 学习项目一 Calendar日历控件 1.在站点下创建一个Calendar页面,并在页面上拖放一个
简析ASP.NET网站的创建与发布过程

一.简单网站创建: 1.首先打开VS, 2.文件-->新建-->网站-->ASP.NET(注意语言选择c#)-->对项目进行命名,这里命名为hopeTest: 3.系统会默认生成一个Default.aspx文件,文件内容如下: <%@ Page Language="C#" CodeFile="Default.aspx.cs" Inherits="_Default" %> <!DOCTYPE html PU
ASP.NET MVC3网站创建与发布（1）

有时候我们有了网站但是却不知道怎么进行发布,这一节我们演示下怎样使用VS2010创建与发布MVC3建立的网站.使用VS2010创建MVC3.0网站,需要下载MVC3.0的安装包,这个大家可以去网络上下载. 1.项目创建打开VS2010,选择文件--新建项目---ASP.NET MVC3 web应用程序,如下图接着选择Razor视图,如下图,点击确定,这样一个MVC3项目就创建完成了 2.网站发布右键选择刚创建的项目,弹出一个下拉菜单,选择 "发布"菜单,弹出 &quo
如何使用ASP.NET制作简单的验证码

大家都知道验证码是以图片形式展示的,而且是动态生成的,这样就需要我们去画出它,那不得不提到是GDI+绘图了科普一下,什么是GDI+? GDI+是图形设备接口(GDI)的高级版本, 提供了各种丰富的图形图像处理功能.GDI+主要由二维矢量图形.图像处理和版式3部分组成.GDI+为使用各种字体.字号和样式来显示文本这种复杂任务提供了大量的支持. 下面说说验证码,对于验证码这样的图片,我觉得是由两部分组成的,一部分是矩形的背景,另一部分是在其上的字母数字组合(有的时候有汉字,有的时候是纯字母或者纯数
创建第一个ASP.NET应用程序（第1节）

这一节我们一起学习创建一个根据用户输入来显示相应的欢迎信息的页面,希望小伙伴们可以和我一起动手操作学习内容: 第一步,创建ASP.NET程序 1.运行 Visual Studio 2008.在菜单栏中选择"文件" →"新建" →"项目"命令,在弹出的"新建项目"的对话框中,选择左侧的"其他项目类型"树形目录中的"Visual Studio 解决方案"选项,在右边"Visual
ASP.NET MVC3模板页的使用（2）

本文为大家演示下MVC3中怎样使用模板页,在传统的webform设计模式中,我们使用masterpage作为模板页,在MVC3 razor视图设计中,我们使用另一种方式作为模板页. 新建一个MVC3项目,在解决方案资源管理中,我们可以看到VIEWS文件夹下面有一个Shared文件夹.在Shared文件夹里面有一个_Layout.cshtml页面.这个就是项目中默认的模板页面.如下图所示 : 1.新建内容页内容页在MVC3中也叫做视图布局页,可以右键选中视图文件夹,通过添加视图来
Asp.Mvc 2.0实现用户注册实例讲解（1）

最近一直在研究ASP.NET MVC,看了一些教程,总觉得印象不是太深刻,于是决定动手写一个系列的MVC教程,一方面是为了加深自己的印象,另一方面也给学习MVC的同学提供一些帮助,作为一个参考资料.本系列的教程将通过一个实例来由浅入深讲解MVC,相关知识点将在我们的实例中为大家讲解. Asp.mvc模式改变了传统的asp.net webform方式,我们在使用MVC开发WEB程序时,要摒弃传统的WEBFORM方式的思想,传统的WEBFORM方式用户拖拉一个按钮,然后双击按钮,就可以在后台写相应的
ASP.NET中验证控件的使用方法

对于这些常用的控件有效性验证,在Asp.Net中有单独的验证控件可供使用.他们可以满足一般的,诸如非空,范围.比较等的验证,为用户登录页面添加输入数据验证功能和验证码功能. 验证控件: Asp.Net中内置的验证控件有:RequiredFieldValidation.RangeValidation.RegularExpressValidation.CompareValidation.CustomValidation和ValidationSummary等六种.其中用户自定义验证控件,由于并不非常常
浅谈ASP.NET MVC应用程序的安全性

前言:保护Web应用程序的安全性看起来时间苦差事,这件必须要做的工作并不能带来太多的乐趣,但是为了回避尴尬的安全漏洞问题,程序的安全性通常还是不得不做的. 1．ASP.NET Web Forms开发人员 (1)因为ASP.NET MVC不像ASP.NET Web Forms那样提供了很多自动保护机制来保护页面不受恶意用户的攻击,所以阅读本博客来了解这方面的问题,更明确的说法是:ASP.NET Web Forms致力于使应用程序免受攻击.例如: 1)服务器组件对显示的值和特性进行HTML编码,以帮
Asp.Mvc 2.0实现用户登录与注销功能实例讲解（2）

这一节讲解下ASP.MVC 2.0的用户登录与注销功能,先讲登录,后说注销.我们这个系列讲的用户登录方式都是FORM表单验证方式.在讲之前先给大家说下<%:%>的功能,<%:%>与<%=%>功能一样,用来动态输出内容. 一.登录 1. 建立MODEL 登录的时候,我们一般只要验证用户名和密码,还有是否保存登录COOKIE,所以我们建立一个MODEL登录类,只需包括3个字段就可以. /// <summary> /// 用户登录MODEL /// </su
Asp.Mvc 2.0用户客户端验证实例讲解（3）

今天给大家讲解下ASP.NET mvc的客户端验证.通常情况下,我们在页面中对输入的内容多要进行客户端验证,客户端验证一般使用JS进行,这里咱们讲解下使用jquery.validate插件进行客户端验证. 首先咱们看下注册页面的验证效果以上验证主要包括 1.用户名不能为空 2.密码不能为空,密码长度不能小于5位数 3.确认密码不能为空,确认密码长度不能小于5位,确认密码必须和密码文本框输入的一致 4.邮箱格式必须正确. 以下是使用jquery.validate插件进行验证的代码 [html]
asp.net之生成验证码的方法集锦（一）

现在很多网站都有注册登录的页面,为了更好的满足用户体验和网站的安全性,很多网站都采用动态生成的图形码或者是附加码进行验证,下面把生成验证码的方法给大家整理如下. 实现验证技术就是在服务器端生成一个随机数,并将其保存在内存中,发送给浏览器,并以图片的形式提交给用户.之前在做项目过程中,完成了一个利用script进行用户注册及登录的验证码时,发现有各种生成验证码的方式,下面主要是几种不同的生成验证码的方式: 1.绘制纯数字的网站验证码本实例实现的是数字验证码技术,即随机生成4位数字作为验证码.在开
ASP.NET 应用程序级验证用户是否登录一般处理程序

大家应该都希望有一种应用程序级的简单处理程序,今天刚好被人问及,所以就简单写了下代码,具体步骤如下: 1.创建一个类库项目,名为IHandlers,名称自定义 2.在类库项目中添加[ASP.NET处理程序],名为HandleSession.cs.打开此文件,添加引用: using System.Web.SessionState 让HandleSession类继承接口IReadOnlySessionState. 以上两步是为了可以使用Session对象. 该类的完整代码如下: 复制代码代码如下:

Asp.net的应用程序对象和页面生存周期

相关推荐

随机推荐