| Element Name |
Description |
|
Not enabled
|
Disables session state.
|
|
In process
|
Stores session state data for a managed-code application in the
worker process where the application runs. This is the default
setting.
|
|
Custom
|
Configures IIS to use a custom provider to handle session state
for ASP.NET applications.
|
|
State Server
|
Enables the Windows Aspnet_state.exe state service and stores
session state outside the worker process where the application
runs. The advantage of this configuration is that session state is
preserved when the application's worker process recycles. Using a
state server is recommended for medium-sized Web applications. The
settings to configure are:
- Connection string - sets the
connection string that is used to connect to the state server.
- Time-out (in seconds) - sets the time,
in seconds, that the connection will be maintained. The default is
10 seconds.
|
Important |
|
|
The Windows state service (Aspnet_state.exe) must be running for
out-of-process session state to take effect. By default, this
service is installed when ASP.NET is installed and is configured
for manual start. You must change the start behavior to
Automatic.
|
|
|
SQL Server
|
Configures IIS to use a SQL Server database to store session
state data instead of storing it in the worker process where the
application runs. The advantage of this configuration is that
session state is preserved when the application's worker process
recycles, or if either the Windows state service or the Web server
goes down. The settings to configure are:
- Connection string - sets the
connection string that is used to connect to the state server.
- Time-out (in seconds) - sets the time,
in seconds, that the connection will be maintained. The default is
10 seconds.
|
|
Important |
|
|
Before you configure a SQL Server for session state, you must
run the InstallSqlState.sql script on the server. By default, this
script is stored in
systemroot\Microsoft.NET\Framework\V2.0.50727.
|
|
|
Enable custom database
|
Enables a custom SQL Server database for storing session state
data.
|
|
Mode
|
Defines how cookies are used to store session state data. The
options are:
- Auto Detect - uses cookies if the
browser supports cookies; otherwise, no cookies are used. For
desktop browsers that are known to support cookies, ASP.NET tries
to use cookies when cookie support is enabled in the browser. When
you use the Auto-Detect cookie mode, you should require that
expired session IDs be regenerated. Doing this lets a Web server
expire and regenerate tokens, which gives a potential attacker less
time to capture a cookie and gain access to Web server content. You
should also consider changing the time-out value to less than the
20-minute default.
- Use Cookies - associates session
information with client information for the duration of a user's
connection to a Web site. Cookies are passed on together with all
requests between a client and a Web server in an HTTP header. Using
cookies is a more efficient way to track session state than any of
the methods that do not use cookies, because cookies do not require
any redirection. Additionally, cookies let users bookmark Web
pages, and they retain state if a user leaves one site to visit
another and then returns to the original site.
|
Note |
|
|
You should consider changing the time-out value to less than the
20-minute default so a potential attacker has less time to capture
a cookie and gain access to Web site content.
|
- Use Device Profile - uses cookies if
the device profile supports cookies, otherwise, no cookies are
used. If the device profile indicates support for cookies, they
will be used regardless of whether the user has disabled cookie
support. When you use the Use Device Profile cookie mode, you
should require that expired session IDs be regenerated. Doing this
lets a Web server expire and regenerate tokens, which gives a
potential attacker less time to capture a cookie and gain access to
Web server content. You should also consider changing the time-out
value to less than the 20-minute default.
- Use URI - embeds the session ID as a
query string in the Uniform Resource Identifier (URI) request, and
then the URI is redirected to the originally requested URL. The
changed URI request is used for the duration of the session, so no
cookie is necessary. When you use a URI, you should require that
expired session IDs be regenerated. Doing this lets a Web server
expire and regenerate tokens, which gives a potential attacker less
time to capture a cookie and gain access to Web server content.
|
|
Name
|
Sets a name for the cookie. The default is
ASP.NET_SessionID.
|
|
Time-out (in minutes)
|
Sets the time, in minutes, that a cookie will persist. The
default is 20 minutes.
|
|
Regenerate expired session ID
|
Tells IIS to reject and reissue session IDs that do not have
corresponding sessions active in the database. By default, this
feature is supported only for cookieless session IDs, but this
feature can be extended in order to manage cookie/arbitrary session
IDs by implementing a custom session ID manager.
|
|
Use hosting identity for impersonation
|
Enables Windows authentication and the host process identity
(either ASP.NET or a Windows service identity) for remote
connections.
|