How to maintain the same session id across multiple web applications in ASP.NET

Question

I have two identical applications setup on IIS on different virtual directories (I have done some workaround to ensure that they both have the same application name). Is there a way to share session id across two asp.net web applications?

Since I'm storing the session in StateServer, they should both be getting the same session data, however, a different session id is created everytime I go from application a to applicatino b. Wouldn't this happen in a load balancing scenario as well? Where when I go to www.test.com, it would redirect that request to server a, and then if I hit it again, it would go to server b, but since it's a different web application, it would create a new session id?

Answer 1

Is your goal to share the session state between 2 applications, not just the session ID? I believe the StateServer also uses the application path as well as the SessionID to store the data so even if the SessionID's were the same you still wouldn't be able to share the data. You might have to write your own session module.

Load balancing web apps don't have this problem because the application path is the same across cluster members.

Answer 2

First, configure the sessionState element in your web.config to use cookieName="SOME_COOKIE_NAME_HERE" in both apps.

Then, just make sure the urls have the same TLD (top-level domain), i.e. app1.mydomain.com and app2.mydomain.com and you should be able to handle the Session_Start event in Global.asax and put this code:

    HttpCookie cookie = new HttpCookie("SOME_COOKIE_NAME_HERE", Session.SessionID.ToString());
    cookie.Expires = DateTime.Now.AddMinutes(20);
    cookie.Domain = "*.mydomain.com";
    cookie.HttpOnly = true;
    Response.SetCookie(cookie);

Also, I would recommend that you go with the SqlServer SessionState Mode.

Answer 3

My initial thought on this is dont store session state in cookies. change this in web.config to other than inProc.

the different available options are as follows

*

  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.

In-Process Mode

In-process mode is the default session state mode and is specified using the InProc SessionStateMode enumeration value. 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. For more information about the Session_OnEnd event, see Session-State Events. [Caution note] Caution:

If you enable Web-garden mode by setting the webGarden attribute to true in the processModel element of the application's Web.config file, do not use InProc session state mode. If you do, data loss can occur if different requests for the same session are served by different worker processes.

State Server Mode

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.
  [Note] Note:

  To improve the security of your application when using StateServer mode, it is recommended that you protect your stateConnectionString value by encrypting the sessionState section of your configuration file. 

The following example shows a configuration setting for StateServer mode where session state is stored on a remote computer named SampleStateServer: Copy Code

[Note] Note:

Objects stored in session state must be serializable if the mode is set to StateServer. For information on serializable objects, see the SerializableAttribute class.

To use StateServer mode in a Web farm, you must have the same encryption keys specified in the machineKey element of your Web configuration for all applications that are part of the Web farm.

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] Note:

Objects stored in session state must be serializable if the mode is SQL Server. For information on serializable objects, see the SerializableAttribute class.

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, as described later in this topic.

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.
  [Note] Note:

  to improve the security of your application when using SQLServer mode, it is recommended that you protect your sqlConnectionString value by encrypting the sessionState section of your configuration file. For details, see Encrypting Configuration Information Using Protected Configuration.

The following example shows a configuration setting for SQLServer mode where session state is stored on a SQL Server named "SampleSqlServer": Copy Code

[Note] Note:

If you specify a trusted connection to your SQL Server in the configuration file using the sessionState element's sqlConnectionString attribute, the SessionStateModule will connect to SQL Server using SQL Server integrated security. The connection will be made using the ASP.NET process identity or the user credentials supplied for the identity configuration element, if they exist. You can specify that the IIS impersonated identity be used instead by specifying and setting the useHostingIdentity attribute of the sessionState configuration element to false.

To configure SQLServer mode for a Web farm, in the configuration file for each Web server, set the sessionState element's sqlConnectionString attribute to point to the same SQL Server database. The path for the ASP.NET application in the IIS metabase must be identical on all Web servers that share session state in the SQL Server database. Installing the Session State Database Using the Aspnet_regsql.exe Tool

To install the session state database on SQL Server, run the Aspnet_regsql.exe tool located in the systemroot\Microsoft.NET\Framework\versionNumber folder on your Web server. Supply the following information with the command:

*

  Thename of the SQL Server instance, using the -S option.
*

  The logon credentials for an account that has permission to create a database on SQL Server. Use the -E option to use the currently logged-on user, or use the -U option to specify a user ID along with the -P option to specify a password.
*

  The -ssadd command-line option to add the session state database.

  By default, you cannot use the Aspnet_regsql.exe tool to install the session state database on SQL Server Express Edition. In order to run the Aspnet_regsql.exe tool to install a SQL Server Express Edition database, you must first enable the Agent XPs SQL Server option using T-SQL commands like the following:
  Copy Code

  EXECUTE sp_configure 'show advanced options', 1
  RECONFIGURE WITH OVERRIDE
  GO

  EXECUTE sp_configure 'Agent XPs', 1
  RECONFIGURE WITH OVERRIDE
  GO

  EXECUTE sp_configure 'show advanced options', 0
  RECONFIGURE WITH OVERRIDE
  GO

  You must run these T-SQL commands for any instance of SQL Server Express Edition where the Agent XPs option is disabled.

By default, the Aspnet_regsql.exe tool will create a database named ASPState containing stored procedures that support SQLServer mode. Session data itself is stored in the tempdb database by default. You can optionally use the -sstype option to change the storage location of session data. The following table specifies the possible values for the -sstype option:

Option

Description

t

Stores session data in the SQL Server tempdb database. This is the default. If you store session data in the tempdb database, the session data is lost if SQL Server is restarted.

p

Stores session data in the ASPState database instead of in the tempdb database.

c

Stores session data in a custom database. If you specify the c option, you must also include the name of the custom database using the -d option.

For example, the following command creates a database named ASPState on a SQL Server instance named "SampleSqlServer" and specifies that session data is also stored in the ASPState database:

aspnet_regsql.exe -S SampleSqlServer -E -ssadd -sstype p [Note] Note:

If you are running ASP.NET 1.0 or ASP.NET 1.1, you cannot use the Aspnet_regsql.exe tool to configure ASP.NET to store session state in a persistent SQL Server database. However, you can obtain scripts to store session state in a persistent database. As an alternative, Web servers running ASP.NET 1.0 or ASP.NET 1.1 can direct persistent session state to a SQL Server that has the ASP.NET 2.0 session state schema installed.

In SQLServer mode, you can configure several computers running SQL Server to work as a failover cluster, which is two or more identical computers running SQL Server that store data for a single database. If one computer running SQL Server fails, another server in the cluster can take over and serve requests without session-data loss. To configure SQL Server mode for a failover cluster, you must specify -sstype p when you execute the Aspnet_regsql.exe tool so that session state data is stored in the ASPState database instead of the tempdb database. Storing session state in the tempdb database is not supported for a SQL Server cluster.

Custom Mode

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

For more information on custom session state store providers, see Implementing a Session-State Store Provider. [Note] Note:

A custom session state store provider will access any secured resource, such as SQL Server, using the ASP.NET process identity or the user credentials supplied to the identity configuration element, if they exist. You can specify that the IIS impersonated identity be used instead by specifying and setting the useHostingIdentity attribute of the sessionState configuration element to false. For more information on the ASP.NET process identity, see Configuring ASP.NET Process Identity and ASP.NET Impersonation.