Web Event Hierarchy

Web Event Hierarchy

Web event classes are organized by inheritance, and all ultimately derive from WebBaseEvent, as shown in Figure. This base class defines some properties that all events have in common, including the date and time the event was raised, a unique ID for the event, two integers representing an event code and a detail code, and among other things, a human-readable message describing the event.

Web event hierarchy

  • WebManagementEvent adds information about the worker process, including process id and name, as well as the account name the process is using.

  • WebApplicationLifetimeEvent is raised whenever an application is compiled, started, or shut down.

  • WebHeartbeatEvent is not normally raised unless you specifically configure a heartbeat interval via web.config. This event allows an administrator to be notified that the application is still running, and it provides some basic statistics about the Web server process, including how many requests are currently executing, how many are queued, how many bytes the managed heap occupies, and so on. To enable this special event, you need to set the heartbeatInterval attribute to something other than its default value of zero on the <healthMonitoring> element in web.config.

  • WebRequestEvent is a base class that you can use for custom events. It is convenient for capturing details about a Web request. We'll talk more about custom events later in this chapter.

  • WebAuditEvent is the base class for all security audits. It adds details about the Web request, including the path, the URL, and the name of the security account being used by the current thread, which can be different than the process' account if you're using impersonation.

  • WebFailureAuditEvent is the base class for all security auditing failures, such as when a user tries to access a page to which she is not authorized.

  • WebAuthenticationFailureAuditEvent is a specific failure audit raised by systems like Membership and Forms authentication when a user fails to authenticate. This class adds the submitted user name to the details being logged.

  • WebViewStateFailureAuditEvent is raised when a user submits a Web form that contains invalid view state. This could indicate that an attacker is attempting to tamper with view state, and adds details about the exception collected when the view state was found to be invalid.

  • WebSuccessAuditEvent and its derived classes can help you audit successful access to sensitive resources. This is one way to provide an audit trail as a user browses your Web site, but keep in mind that it generates a lot of events.

  • WebBaseErrorEvent is the base class for all Web events that represent exceptions raised in the worker process. This class adds details about the exception that occurred.

  • WebErrorEvent is raised when a configuration or compilation problem occurs with your application. This class adds details about the current request, as well as information about the thread executing the request including thread id, whether the thread is impersonating, and the user account the thread is running under, which could be different from the process' identity if you're using impersonation.

  • WebRequestErrorEvent is raised when an error results from a particular request, for example, unhandled exceptions in ASPX pages or posted data that is too large. It includes the same details as WebErrorEvent.

Event classes are generally designed to represent a category of events. For the details of any given event, look at the EventCode and Message, and in many cases the DetailCode. For a comprehensive list of event codes, look at the documentation for the WebEventCodes enumeration.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows