• Choose a category
• All
• Classic-Fiction

By Root 5714 0

cookies and visit a page. Grab the URL with the session ID as it appears in the browser’s address bar, and send it immediately in an e-mail to a friend. Have your friend paste the URL in his or her own machine and click Go. Your friend will gain access to your session state as long as the session is active.

The session ID is certainly not well-protected information (and probably couldn’t work otherwise). For the safety of a system, an unpredictable generator of IDs is key because it makes it difficult to guess a valid session ID. With cookieless sessions, the session ID is exposed in the address bar and visible to all. For this reason, if you are storing private or sensitive information in the session state, it is recommended that you use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to encrypt any communication between the browser and server that includes the session ID.

In addition, you should always provide users the ability to log out and call the Abandon method when they think security has been breached in this way. This contrivance reduces the amount of time available for anybody attempting to use your session ID to exploit data stored in the session state. And, speaking of security, it is important that you configure the system to avoid the reuse of expired session IDs when cookieless sessions are used. This behavior is configurable in ASP.NET through the section, as you can read in the following section.

Cookieless Sessions and SEO

Cookieless sessions are also problematic from a Search-Engine Optimization (SEO) perspective. Pages based on cookieless sessions are poorly ranked by Web spiders such as Googlebot. The reason is that every time the spider attempts to crawl the page, ASP.NET generates a different session ID, which results in a different URL for the same content. So a crawler typically concludes that you have several pages with the same content and gives you a low ranking.

An effective workaround for this issue is using UseDeviceProfile (described in Table 17-7) instead of the default value. In addition, you create in web.config a browser profile for each of the major crawlers, such as Googlebot. In the profile, you just declare that any agent that contains the word “Googlebot” in the user agent string should be treated like a browser that supports cookies. In this way, ASP.NET will not append the session ID to the URL. It’s not really a clean solution, but it does work. You can add a new profile for each crawler that is not indexing your pages well enough.

Configuring the Session State

The section groups the settings you can apply to configure the behavior of ASP.NET session state. Here’s what it looks like:

mode="[Off|InProc|StateServer|SQLServer|Custom]"

timeout="number of minutes"

cookieName="session identifier cookie name"

cookieless=

"[true|false|AutoDetect|UseCookies|UseUri|UseDeviceProfile]"

regenerateExpiredSessionId="[True|False]"

sessionIDManagerType="session manager type"

sqlConnectionString="sql connection string"

sqlCommandTimeout="number of seconds"

allowCustomSqlDatabase="[True|False]"

useHostingIdentity="[True|False]"

stateConnectionString="tcpip=server:port"

stateNetworkTimeout="number of seconds"

customProvider="custom provider name"

compressionEnabled="[True|False]"

sqlConnectionRetryInterval="number of seconds">

...

Table 17-8 details the goals and characteristics of the various attributes.

Table 17-8. Attributes

Mode

Description

allowCustomSqlDatabase

If true, enables specifying a custom database table to store session data instead of using the standard ASPState.

compressionEnabled

Indicates whether the session state content is compressed during serialization and deserialization to and from an out-of-process provider. Compression is disabled by default and, if enabled, uses the built-in Gzip stream. This feature is available only in ASP.NET 4.

cookieless

Specifies how to communicate the session ID to clients.

cookieName