Windows Authentication

Windows Authentication

In this article we will understand the concepts of Windows Authentication in a neat and clear way.

Contents:

·         Definitions of few keywords to understand Windows Authentication.

·         What is Windows Authentication.

·         Why Windows Authentication.

·         How Windows Authentication is implemented in ASP.NET Application.

·         Configuring impersonation in an application.

Authentication: Authentication is the process of determining the identity of a user based on the user’s credentials. The user’s credentials are usually in the form of user ID and password, which is checked against any credentials' store such as database. If the credentials provided by the user are valid, then the user is considered an authenticated user.

Authorization: After successful authentication, deciding which resources a user can access based on their identity and checking whether the authenticated user has sufficient rights to access the requested resource is authorization.

Impersonation: Impersonation is a process in which  user accesses the resources(Ex:Files,DB…) by using the identity of another user.

Ex: If anonymous(not logged in/not Authenticated) access is enabled for a website in IIS, then IIS runs all the users' requests using the identity of the IUSR_machinename account, which is created by IIS. This is the default option in IIS.

WindowsIdentity: It represents the current Windows User.

Authentication Providers:

In ASP.NET authentication is done by both IIS and ASP.NET. ASP.NET implements authentication through authentication providers that contains the code necessary to authenticate the requestor's credentials.  There are three types of authentication providers built into ASP.NET. They are:

1.      Windows Authentication Provider.

2.      Forms Authentication Provider.

3.      Passport Authentication Provider.

Windows Authentication Provider: Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications. 

Why Windows Authentication:

1.      Windows authentication is generally used if the users accessing the application belong to same organization.

2.      This authentication method uses Windows accounts for validating users' credentials. This type of authentication is very good for intranet Web sites where we know our users.

How Windows Authentication is implemented in ASP.NET Application.

With this type of authentication, initially IIS performs the authentication through one of its authentication options (e.g., basic, digest, Integrated Windows, or some combination of them). After successful authentication, IIS passes the credentials of the authenticated user to the ASP.NET thread. Selection of appropriate identity for the ASP.NET worker thread is performed by using the process defined under the ASP.NET Impersonation section. Based on the credentials supplied by IIS, windows identity is created by WindowsAuthenticationModule module in ASP.NET. This identity is set as current user identity (setting the security information for the current HTTP request)for the application. This is the default authentication mode in ASP.NET and it is set in web.config file of the application using below code:

 <system.web>

  <authentication mode="Windows"/>

</system.web>

Although the Windows Authentication mode sets the value of the current User property to a WindowsIdentity based on the credentials supplied by IIS. The Windows identity supplied to the operating system used for permission checking, such as NTFS file permissions, or for connecting to a database using integrated security is the identity of the ASP.NET process. On Microsoft Windows 2000 and Windows XP Professional, this is the identity of the ASP.NET worker process, which is the local ASPNET account. On Windows Server 2003, this is the identity of the IIS Application Pool that the ASP.NET application is part of. Which is the NETWORK SERVICE account.

We can configure the Windows identity of our ASP.NET application as the Windows identity supplied by IIS by enabling impersonation. Here ASP.NET application impersonates the identity supplied by IIS for all tasks that the Windows operating system authenticates, including file and network access.

Configuring impersonation in an application.

In machine.config file it is configured as below:

<processModel enable="true" username="machine"

password="AutoGenerate" ....... />

In the above line, "machine" is a special value that causes the ASP.NET worker process to run under the less-privileged account, ASPNET.

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.

•           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.

•           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 <processModel> tag in the Web.config file)

•           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.

To enable impersonation for our Web application, in the application's Web.config file set the impersonate attribute of the identity element to true, as below:

<system.web>

  <authentication mode="Windows"/>

  <identity impersonate="true"/>

</system.web>

There are three ways of defining impersonation:

• <identity impersonate="true"/> This means impersonation for the ASP.NET worker thread is enabled.

• <identity impersonate="true" name="username" password="password"/> 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.

• <identity impersonate="false"/> This means impersonation for the ASP.NET worker thread is not enabled.

Windows Authentication

Windows Authentication

In this article we will cover Windows Authentication.

Contents:

• Definitions of few keywords to understand Windows Authentication.
• What is Windows Authentication.
• Why Windows Authentication.
• How Windows Authentication is implemented in ASP.NET Application.
• Configuring impersonation in an application.
Authentication: Authentication is the process of determining the identity of a user based on the user’s credentials. The user’s credentials are usually in the form of user ID and password, which is checked against any credentials' store such as database. If the credentials provided by the user are valid, then the user is considered an authenticated user.
Authorization: After successful authentication, deciding which resources a user can access based on their identity and checking whether the authenticated user has sufficient rights to access the requested resource is authorization.
Impersonation: Impersonation is a process in which user accesses the resources(Ex:Files,DB…) by using the identity of another user.
Ex: If anonymous(not logged in/not Authenticated) access is enabled for a website in IIS, then IIS runs all the users' requests using the identity of the IUSR_machinename account, which is created by IIS. This is the default option in IIS.
WindowsIdentity: It represents the current Windows User.

Authentication Providers:

In ASP.NET authentication is done by both IIS and ASP.NET. ASP.NET implements authentication through authentication providers that contains the code necessary to authenticate the requestor's credentials. There are three types of authentication providers built into ASP.NET. They are:
1. Windows Authentication Provider.
2. Forms Authentication Provider.
3. Passport Authentication Provider.

Windows Authentication Provider: Provides information on how to use Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication to secure ASP.NET applications.
Why Windows Authentication:
1. Windows authentication is generally used if the users accessing the application belong to same organization.
2. This authentication method uses Windows accounts for validating users' credentials. This type of authentication is very good for intranet Web sites where we know our users.

How Windows Authentication is implemented in ASP.NET Application.

With this type of authentication, initially IIS performs the authentication through one of its authentication options (e.g., basic, digest, Integrated Windows, or some combination of them). After successful authentication, IIS passes the credentials of the authenticated user to the ASP.NET thread. Selection of appropriate identity for the ASP.NET worker thread is performed by using the process defined under the ASP.NET Impersonation section. Based on the credentials supplied by IIS, windows identity is created by WindowsAuthenticationModule module in ASP.NET. This identity is set as current user identity (setting the security information for the current HTTP request)for the application. This is the default authentication mode in ASP.NET and it is set in web.config file of the application using below code:
<


Although the Windows Authentication mode sets the value of the current User property to a WindowsIdentity based on the credentials supplied by IIS. The Windows identity supplied to the operating system used for permission checking, such as NTFS file permissions, or for connecting to a database using integrated security is the identity of the ASP.NET process. On Microsoft Windows 2000 and Windows XP Professional, this is the identity of the ASP.NET worker process, which is the local ASPNET account. On Windows Server 2003, this is the identity of the IIS Application Pool that the ASP.NET application is part of. Which is the NETWORK SERVICE account.
We can configure the Windows identity of our ASP.NET application as the Windows identity supplied by IIS by enabling impersonation. Here ASP.NET application impersonates the identity supplied by IIS for all tasks that the Windows operating system authenticates, including file and network access.


Configuring impersonation in an application.

In machine.config file it is configured as below:

In the above line, "machine" is a special value that causes the ASP.NET worker process to run under the less-privileged account, ASPNET.

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.

• 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.
• 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)
• 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.
To enable impersonation for our Web application, in the application's Web.config file set the impersonate attribute of the identity element to true, as below:





There are three ways of defining impersonation:

• This means impersonation for the ASP.NET worker thread is enabled.
• 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.
• This means impersonation for the ASP.NET worker thread is not enabled.

Session

session management using sessions:

As we know http protocol used for web is stateless protocol. each request for a webpage is treated as a new request, and information from one request is not available by default to the next request. To overcome this limitation of Web-based applications, ASP.NET includes a number of features for managing state—that is, for storing information between requests. You can use state management to track any piece of information or data that affects the behavior of the application: catalogs, shopping carts, user options, lists of reviews, and hit counters are all examples.

In ASP.NET, a new instance of the Web page class is created each time the page is posted to the server. In traditional Web programming, this would typically mean that all information associated with the page and the controls on the page would be lost with each round trip. For example, if a user enters information into a text box, that information would be lost in the round trip from the browser or client device to the server.

To overcome this inherent limitation of traditional Web programming, ASP.NET includes several options that help you preserve data on both a per-page basis and an application-wide basis. These features are as follows:
• View state
• Control state
• Hidden fields
• Cookies
• Query strings
• Application state –Server side
• Session state–Server side
• Profile Properties–Server side
Some of these are server side and some are client side state management techniques. In this article we will see about one of the server side state management techniques: Session State
ASP.NET session state enables you to store and retrieve values for a user as the user navigates ASP.NET pages in a Web application. HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all ASP.NET applications.

In an ASP.NET page, the current session variables are exposed through the Session property of the Page object.

The collection of session variables is indexed by the name of the variable or by an integer index. Session variables are created by referring to the session variable by name. You do not have to declare a session variable or explicitly add it to the collection. The following example shows how to create session variables in an ASP.NET page for the value of a counter.
Visual Basic
Session("Counter") = 1
C#
Session["Counter "] = 1;

Session variables can be any valid .NET Framework type.
The value returned by the “Counter” session variable must be cast to the appropriate type when you retrieve it from the SessionStateItemCollection.

ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
• InProc mode, which stores session state in memory on the Web server. This is the default.
• StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• Custom mode, which enables you to specify a custom storage provider.
• Off mode, which disables session state.
You can specify which mode you want ASP.NET session state to use by assigning a SessionStateMode enumeration values to the mode attribute of the sessionState element in your application's Web.config file. You can view the currently selected session state by accessing the value of the HttpSessionState.Mode property.
In-Process Mode:
In-process mode is the default session state mode
In-process mode stores session state values and variables in memory on the local Web server. It is the only mode that supports the Session_OnEnd event.
StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed. The ASP.Net state service is installed at the following location:
systemroot\Microsoft.NET\Framework\versionNumber\aspnet_state.exe
To configure an ASP.NET application to use StateServer mode, in the application's Web.config file do the following:
• Set the mode attribute of the sessionState element to StateServer.
• Set the stateConnectionString attribute to tcpip=serverName:42424.
• The following example shows a configuration setting for StateServer mode where session state is stored on a remote computer named TestStateServer:
Copy Code





Note:
Objects stored in session state must be serializable if the mode is set to StateServer

SQL SERVER MODE:

SQLServer mode stores session state in a SQL Server database. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Note:
Objects stored in session state must be serializable if the mode is SQL Server.
To use SQLServer mode, you must first be sure the ASP.NET session state database is installed on SQL Server. You can install the ASP.NET session state database using the Aspnet_regsql.exe tool
To configure an ASP.NET application to use SQLServer mode, do the following in the application's Web.config file:
• Set the mode attribute of the sessionState element to SQLServer.
• Set the sqlConnectionString attribute to a connection string for your SQL Server database.
• The following example shows a configuration setting for SQLServer mode where session state is stored on a SQL Server named "TestSqlServer":







Custom mode specifies that you want to store session state data using a custom session state store provider. When you configure your ASP.NET application with a Mode of Custom, you must specify the type of the session state store provider using the providers sub-element of the sessionState configuration element. You specify the provider type using an add sub-element and include both a type attribute that specifies the provider's type name and a name attribute that specifies the provider instance name. The name of the provider instance is then supplied to the customProvider attribute of the sessionState element to configure ASP.NET session state to use that provider instance for storing and retrieving session data.
The following example shows elements from a Web.config file that specify that ASP.NET session state use a custom session state store provider:
Copy Code













A custom session state store provider will access any secured resource, such as SQL Server

Session Identifiers
Sessions are identified by a unique identifier that can be read by using the SessionID property. When session state is enabled for an ASP.NET application, each request for a page in the application is examined for a SessionID value sent from the browser. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is sent to the browser with the response.
By default, SessionID values are stored in a cookie. However, you can also configure the application to store SessionID values in the URL for a "cookieless" session.
A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, the session is considered expired. Requests made with an expired SessionID value result in a new session.
Session Events
ASP.NET provides two events that help you manage user sessions. The Session_OnStart event is raised when a new session starts, and the Session_OnEnd event is raised when a session is abandoned or expires. Session events are specified in the Global.asax file for an ASP.NET application.
The Session_OnEnd event is not supported if the session Mode property is set to a value other than InProc, which is the default mode.
Note:
If the Global.asax file or Web.config file for an ASP.NET application is modified, the application will be restarted and any values stored in application state or session state will be lost. Be aware that some anti-virus software can update the last-modified date and time of the Global.asax or Web.config file for an application.
Configuring Session State
Session state is configured by using the sessionState element of the system.web configuration section. You can also configure session state by using the EnableSessionState value in the @ Page directive.
The sessionState element enables you to specify the following options:
• The mode in which the session will store data.
• The way in which session identifier values are sent between the client and the server.
• The session Timeout value.
• Supporting values that are based on the session Mode setting.
The following example shows a sessionState element that configures an application for SQLServer session mode. It sets the Timeout value to 30 minutes, and specifies that session identifiers are stored in the URL.


You can disable session state for an application by setting the session-state mode to Off. If you want to disable session state for only a particular page of an application, you can set the EnableSessionState value in the @ Page directive to false. The EnableSessionState value can also be set to ReadOnly to provide read-only access to session variables.

Connect to Database in VB.NET

This post shows how to connect to database and execute select query in VB.NET.

Please follow the below steps

1. If the database name is : NorthWindDB.

2. in web.config file add the following code.







3. In the code file, import the following namespaces.

Imports System.Data;
Imports System,Data.SqlClient;


4. Add the reference to System.Configuration namespace. By right clicking the project -> click Add Reference -> select System.Configuration -> ok.

Write the following code to connect to the database and execute the query "select * from Emp". This query retreives all the rows from the Emp table of the NorthWindDB database.

5.Dim con as New SqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings("NorthWindDB").ConnectionString()

dim cmd as New SqlCommand(con,"select * from Emp")

dim dr as SqlDataReader = cmd.ExecuteReader()

while(dr.Read())

//Process the data as per your requirement.

End While

Abbreviations for some .Net terms

Full form for some of the .Net terms

API: application programming interface
asmx: Active Server Methods. It is a Webservice extension.
ascx: Active Server Controls. It is a User control Extension.
ASPX: Active server pages.
BCL: Base Class Library
CLR: Common Language Runtime
DLL: dynamic-link library
WSDL: Web Service Description Language. IT describes the webservice.
HTML: HyperText Markup language.
SOAP: Simple Object Access Protocol. It is language neutral. HTML + XML is soap.
XML: Extensible markup language.

session

As we know http protocol used for web is stateless protocol. each request for a webpage is treated as a new request, and information from one request is not available by default to the next request. To overcome this limitation of Web-based applications, ASP.NET includes a number of features for managing state—that is, for storing information between requests. You can use state management to track any piece of information or data that affects the behavior of the application: catalogs, shopping carts, user options, lists of reviews, and hit counters are all examples.

In ASP.NET, a new instance of the Web page class is created each time the page is posted to the server. In traditional Web programming, this would typically mean that all information associated with the page and the controls on the page would be lost with each round trip. For example, if a user enters information into a text box, that information would be lost in the round trip from the browser or client device to the server.

To overcome this inherent limitation of traditional Web programming, ASP.NET includes several options that help you preserve data on both a per-page basis and an application-wide basis. These features are as follows:
• View state
• Control state
• Hidden fields
• Cookies
• Query strings
• Application state –Server side
• Session state–Server side
• Profile Properties–Server side
Some of these are server side and some are client side state management techniques. In this article we will see about one of the server side state management techniques: Session State
ASP.NET session state enables you to store and retrieve values for a user as the user navigates ASP.NET pages in a Web application. HTTP is a stateless protocol. This means that a Web server treats each HTTP request for a page as an independent request. The server retains no knowledge of variable values that were used during previous requests. ASP.NET session state identifies requests from the same browser during a limited time window as a session, and provides a way to persist variable values for the duration of that session. By default, ASP.NET session state is enabled for all ASP.NET applications.

In an ASP.NET page, the current session variables are exposed through the Session property of the Page object.

The collection of session variables is indexed by the name of the variable or by an integer index. Session variables are created by referring to the session variable by name. You do not have to declare a session variable or explicitly add it to the collection. The following example shows how to create session variables in an ASP.NET page for the value of a counter.
Visual Basic
Session("Counter") = 1
C#
Session["Counter "] = 1;

Session variables can be any valid .NET Framework type.
The value returned by the “Counter” session variable must be cast to the appropriate type when you retrieve it from the SessionStateItemCollection.

ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
• InProc mode, which stores session state in memory on the Web server. This is the default.
• StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• Custom mode, which enables you to specify a custom storage provider.
• Off mode, which disables session state.
You can specify which mode you want ASP.NET session state to use by assigning a SessionStateMode enumeration values to the mode attribute of the sessionState element in your application's Web.config file. You can view the currently selected session state by accessing the value of the HttpSessionState.Mode property.
In-Process Mode:
In-process mode is the default session state mode
In-process mode stores session state values and variables in memory on the local Web server. It is the only mode that supports the Session_OnEnd event.
StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed. The ASP.Net state service is installed at the following location:
systemroot\Microsoft.NET\Framework\versionNumber\aspnet_state.exe
To configure an ASP.NET application to use StateServer mode, in the application's Web.config file do the following:
• Set the mode attribute of the sessionState element to StateServer.
• Set the stateConnectionString attribute to tcpip=serverName:42424.
• The following example shows a configuration setting for StateServer mode where session state is stored on a remote computer named TestStateServer:



stateConnectionString="tcpip=TestStateServer:42424"
cookieless="false"
timeout="20"/>


Note:
Objects stored in session state must be serializable if the mode is set to StateServer

SQL SERVER MODE:

SQLServer mode stores session state in a SQL Server database. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Note:
Objects stored in session state must be serializable if the mode is SQL Server.
To use SQLServer mode, you must first be sure the ASP.NET session state database is installed on SQL Server. You can install the ASP.NET session state database using the Aspnet_regsql.exe tool
To configure an ASP.NET application to use SQLServer mode, do the following in the application's Web.config file:
• Set the mode attribute of the sessionState element to SQLServer.
• Set the sqlConnectionString attribute to a connection string for your SQL Server database.
• The following example shows a configuration setting for SQLServer mode where session state is stored on a SQL Server named "TestSqlServer":



sqlConnectionString="Integrated Security=SSPI;data
source=TestSqlServer;" />



Custom mode specifies that you want to store session state data using a custom session state store provider. When you configure your ASP.NET application with a Mode of Custom, you must specify the type of the session state store provider using the providers sub-element of the sessionState configuration element. You specify the provider type using an add sub-element and include both a type attribute that specifies the provider's type name and a name attribute that specifies the provider instance name. The name of the provider instance is then supplied to the customProvider attribute of the sessionState element to configure ASP.NET session state to use that provider instance for storing and retrieving session data.
The following example shows elements from a Web.config file that specify that ASP.NET session state use a custom session state store provider:



connectionString="DSN=SessionState;" />



mode="Custom"
customProvider="OdbcSessionProvider">

type="Samples.AspNet.Session.OdbcSessionStateStore"
connectionStringName="OdbcSessionServices"
writeExceptionsToEventLog="false" />




A custom session state store provider will access any secured resource, such as SQL Server

Session Identifiers
Sessions are identified by a unique identifier that can be read by using the SessionID property. When session state is enabled for an ASP.NET application, each request for a page in the application is examined for a SessionID value sent from the browser. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is sent to the browser with the response.
By default, SessionID values are stored in a cookie. However, you can also configure the application to store SessionID values in the URL for a "cookieless" session.
A session is considered active as long as requests continue to be made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, the session is considered expired. Requests made with an expired SessionID value result in a new session.
Session Events
ASP.NET provides two events that help you manage user sessions. The Session_OnStart event is raised when a new session starts, and the Session_OnEnd event is raised when a session is abandoned or expires. Session events are specified in the Global.asax file for an ASP.NET application.
The Session_OnEnd event is not supported if the session Mode property is set to a value other than InProc, which is the default mode.
Note:
If the Global.asax file or Web.config file for an ASP.NET application is modified, the application will be restarted and any values stored in application state or session state will be lost. Be aware that some anti-virus software can update the last-modified date and time of the Global.asax or Web.config file for an application.
Configuring Session State
Session state is configured by using the sessionState element of the system.web configuration section. You can also configure session state by using the EnableSessionState value in the @ Page directive.
The sessionState element enables you to specify the following options:
• The mode in which the session will store data.
• The way in which session identifier values are sent between the client and the server.
• The session Timeout value.
• Supporting values that are based on the session Mode setting.
The following example shows a sessionState element that configures an application for SQLServer session mode. It sets the Timeout value to 30 minutes, and specifies that session identifiers are stored in the URL.

cookieless="true "
regenerateExpiredSessionId="true "
timeout="30"
sqlConnectionString="Data Source=MySqlServer;Integrated Security=SSPI;"
stateNetworkTimeout="30"/>
You can disable session state for an application by setting the session-state mode to Off. If you want to disable session state for only a particular page of an application, you can set the EnableSessionState value in the @ Page directive to false. The EnableSessionState value can also be set to ReadOnly to provide read-only access to session variables.

best institute for dotnet

deccansoft is the best institute for learning dotnet. sandeepsoni and harish are the best faculty there. real time knowledge and basics are cleared.