Differences Between ItemCreated, ItemDataBound and ItemCommand

The important events raised by DataGrid, DataList, Repeater

• ItemCreated
• ItemDataBound
• ItemComman

When a datagrid, datalist or repeater is bound to a data source say a dataset it consists of tables and each table consists of data rows. For each record in the DataSource, a new DataWebControlNameItem instance is created and appended to the Web Control. After the DataWebControlNameItem has been created, its dataitem property is set to the value of the current DataSource record.

The ItemCreated event fires once for every DataWebControlNameItem added to the data Web control. It fires before the DataWebControlNameItem's DataItem property is assigned. The ItemDataBound event also fires once for every DataWebControlNameItem added to the data Web control, but this event fires after the DataWebControlNameItem's DataItem property is assigned. Finally, the ItemCommand event fires whenever the Command event for a Button or LinkButton within the data Web control fires.

How ASP.NET Impersonation Works

ASP.NET Impersonation

Before delving into the details of ASP.NET impersonation, we need to be clear about a few concepts. Actually there is one instance of aspnet_wp.exe per processor that serves all the Web applications hosted on a box. This worker process always runs under the security context defined by the tag. The aspnet_wp.exe creates a separate thread, called worker thread, for servicing each client request. We have to distinguish between the server process and the worker threads in order to understand the impersonation and security details of ASP.NET.

With ASP.NET impersonation, the thread servicing the client request can optionally execute with the identity of the client. Let me explain it in detail.

IIS always maps a user request to some Windows account; in case of anonymous access, this is IUSR_machinename account or any other account that has been defined to be used with anonymous access; in the case of Windows authentication, this is the account whose credentials are provided by the Web site user. After successful authentication, IIS forwards this logged-in user's identity to the ASP.NET worker thread. Now the ASP.NET worker thread has the following three options:

1. It can run under the identity defined by the tag.
2. It can run under the client identity passed to it by IIS.
3. It can run under the identity of the user whose credentials have been listed for impersonation.

Now the decision depends on the impersonation settings for the ASP.NET application.

1. If impersonation is not enabled, then the ASP.NET worker thread runs under the identity of the ASP.NET worker process (which has been defined by using the tag in the Web.config file)
2. If impersonation is enabled and any specific Windows account has not been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the client identity passed to it by IIS.
3. If impersonation is enabled and a specific Windows account has been listed in the Web.config file for impersonation, then the ASP.NET worker thread runs under the identity generated using that account.

Impersonation for ASP.NET applications can be set up by using the tag in the Web.config file. We can specify impersonation in the following three ways:

1. This means impersonation for the ASP.NET worker thread is enabled.
2. This means impersonation for the ASP.NET worker thread is enabled, but the worker thread will run under the identity that will be generated by using the credentials specified by username and password attributes.
3. This means impersonation for the ASP.NET worker thread is not enabled.