Asp. Global.asax in net and the life cycle of Web applications

Asp.net|web

Asp. Global.asax in net and the life cycle of Web applications

Global.asax files, sometimes called asp.net application files, provide a way to respond to application-level or module-level events in a central location. You can use this file to implement security for your application and some other tasks.
The Global.asax file is configured for any direct HTTP request (via URL) to be rejected automatically, so the user cannot download or view its contents. The ASP.net page framework automatically identifies any changes made to the Global.asax file. After the Global.asax is changed, the asp.net page framework restarts the application, including closing all browser sessions, removing all state information, and restarting the application domain.

The Global.asax file inherits from the HttpApplication class, which maintains a pool of HttpApplication objects and assigns objects from the object pool to the application when needed. The Global.asax file contains the following events:

· Application_init: This event is triggered when an application is instantiated or when it is invoked for the first time. It will be invoked for all HttpApplication object instances.

· Application_disposed: Triggers before the application is destroyed. This is the ideal place to clear previously used resources.

· Application_Error: The event is triggered when an unhandled exception is encountered in the application.

· Application_Start: The event is triggered when the first instance of the HttpApplication class is created. It allows you to create objects that can be accessed by all HttpApplication instances.

· Application_End: The event is triggered when the last instance of the HttpApplication class is destroyed. It is only triggered once in the life cycle of an application.

· Application_BeginRequest: Triggered when an application request is received. For a request, it is the first event that is triggered, and the request is typically a page request (URL) entered by the user.

· Application_EndRequest: The last event requested for the application.

· Application_prerequesthandlerexecute: The event is triggered before the ASP.net page framework starts executing an event handler such as a page or Web service.

· Application_postrequesthandlerexecute: The event is triggered when an event handler is executed at the end of the ASP.net page frame.

· Applcation_presendrequestheaders: The event is triggered when the ASP.net page frame sends an HTTP header to the requesting client (browser).

· Application_presendcontent: This event is triggered when the ASP.net page frame sends content to the requesting client (browser).

· Application_acquirerequeststate: When the asp.net page frame gets the current state (session state) associated with the current request, the event is triggered.

· Application_releaserequeststate: This event is triggered when all event handlers are executed in the ASP.net page framework. This will cause all the state modules to hold their current state data.

· Application_resolverequestcache: The event is triggered when an authorization request is completed on the ASP.net page frame. It allows caching modules to service requests from the cache, bypassing the execution of event handlers.

· Application_updaterequestcache: When the asp.net page framework completes execution of an event handler, the event is triggered so that the cache module stores the response data for use in response to subsequent requests.

· Application_AuthenticateRequest: This event is triggered when the security module establishes a valid identity for the current user. At this point, the user's credentials will be validated.

· Application_authorizerequest: The event is triggered when the security module confirms that a user can access the resource.

· Session_Start: The event is triggered when a new user accesses the application Web site.

· Session_End: This event is triggered when a user's session times out, ends, or when they leave the application Web site.

One of the key issues in using these events is to know the order in which they are triggered. The Application_init and Application_Start events are triggered once the application is first started. Similarly, application_disposed and Application_End events are triggered once when the application terminates. In addition, session-based events (Session_Start and session_end) are used only when the user enters and leaves the site. The remaining events handle application requests, which are triggered in the following order:

· Application_BeginRequest

· Application_AuthenticateRequest

· Application_authorizerequest

· Application_resolverequestcache

· Application_acquirerequeststate

· Application_prerequesthandlerexecute

· Application_presendrequestheaders

· Application_presendrequestcontent

· << Execute Code >>

· Application_postrequesthandlerexecute

· Application_releaserequeststate

· Application_updaterequestcache

· Application_EndRequest

These events are often used for security purposes. The following example of C # illustrates a different Global.asax event, which uses the Application_authenticate event to complete the form based authentication of the cookie. In addition, the Application_Start event populates an application variable, while session_start fills a session variable. The Application_Error event displays a simple message indicating the error that occurred.

protected void Application_Start (Object sender, EventArgs e) {
application["Title"] = "builder.com Sample";
}
protected void Session_Start (Object sender, EventArgs e) {
session["Startvalue"] = 0;
}
protected void Application_AuthenticateRequest (Object sender, EventArgs e) {
Extract The Forms authentication Cookies
string cookiename = Formsauthentication.formscookiename;
HttpCookie Authcookie = Context.request.cookies[cookiename];
if (null = = Authcookie) {
There is no authentication cookie.
Return
}
FormsAuthenticationTicket AuthTicket = null;
try {
AuthTicket = Formsauthentication.decrypt (Authcookie.value);
catch (Exception ex) {
Log exception Details (omitted for simplicity)
Return
}
if (null = = AuthTicket) {
Cookie failed to decrypt.
Return
}
When the ticket is created, the UserData property is assigned
A pipe delimited string of role names.
STRING[2] Roles
Roles[0] = "one"
ROLES[1] = "Two"
Create an Identity object
FormsIdentity id = new FormsIdentity (AuthTicket);
This principal'll flow throughout the request.
GenericPrincipal principal = new GenericPrincipal (ID, roles);
Attach the new principal object to the current HttpContext object
Context.User = Principal;
}
protected void Application_Error (Object sender, EventArgs e) {
Response.Write ("Error encountered.");
}