asp.net: moving from session variables to cookies

Question

My forms are losing session variables on shared hosting very quickly (webhost4life), and I think I want to replace them with cookies. Does the following look reasonable for tracking an ID from form to form:

if(Request.Cookies["currentForm"] == null)
   return;
projectID = new Guid(Request.Cookies["currentForm"]["selectedProjectID"]);
Response.Cookies["currentForm"]["selectedProjectID"] = Request.Cookies["currentForm"]["selectedProjectID"];

Note that I am setting the Response cookie in all the forms after I read the Request cookie. Is this necessary? Do the Request cookies copy to the Response automatically?

I'm setting no properties on the cookies and create them this way:

Response.Cookies["currentForm"]["selectedProjectID"] = someGuid.ToString();

The intention is that these are temporary header cookies, not persisted on the client any longer than the browser session. I ask this since I don't often write websites.

Answer 1

You might consider using this little library:

http://www.codeproject.com/KB/aspnet/Univar.aspx

It can automatically switch to the session whenever the cookie is unavailable. It also has a server side implementation of the cookie whereby all cookies are stored on the server and asp.net authentification can be used to identify the user.

Answer 2

For Sharing hosting the best approach is to use SQL Session State.

It's a little bit slower but much more reliable.

I had the same problems back in the days and my Memory Sessions were always getting erased, this happends because someone on the same hosting environment didn't know how to accomplish stings and IIS just reset the Application Pool, or it could even do by Auto Refresh the AppPool from the Hosting point of View (so no website will hang).

Since I started to use SQL State ... I just must say WOW!

you have total control in everything, even set the timeout (Memory Sessions are set by the machine config and no matter what you set in code or web config you will never override that setting)

and you gain something new, if you change the code, you users will not need to left the website to re.login again as they will continue from their existing session.

Setting it up it's fairly easy and you have a ton of examples on how to accomplish such behavior.

no matter what you do, DO NOT GO to cookies as they are not reliable!

Answer 3

I was a webhost4life customer up until two months ago, the issue I was experiencing was the application pool being recycled frequently - probably because the host had some kind of problem. In the end I moved to a VPS and never looked back (not a webhost4life VPS either).

Answer 4

The research I've done into cookies suggests they would not be a desirable alternative to session variables. Browsers enforce arbitrary limits on the number of cookies that can exist at any one time as well as the number per site. They are also prone to being dropped randomly.

You can enable cookieless sessions. There are some potential issues but it might work for your site.

Answer 5

I would suspect that the reason you might be loosing session variables is that your application is running in a web garden. This means two or more processes are running your application.

In your web.config there should be sessionState tag. If mode="InProc" then try setting mode="StateServer". This will cause all the processeses hosting your application to use the session state server to store the session state elements. Also check the timeout as was mentioned previously.

Answer 6

Before changing any code, I would investigate why session variables are disappearing.

Perhaps it is as simple as changing the timeout setting in the web.config?

Here's a list of the session state settings in the config file: Session Element on MSDN

====================================================

Oh yeah, one other thing to try in relation to your comment:

If my memory serves me, we had some issues in the past when deploying to a web garden/farm where multiple web sites on the same server would "clash". To get round this we explicitly names the cookie as so:

<authentication mode="Forms" >
    <forms loginUrl="your-login-page.aspx" 
        cookieless="AutoDetect" 
        name=".A-NAME-WHICH-IS-UNIQUE" /> 
</authentication>

Name: Optional attribute. Specifies the HTTP cookie to use for authentication. If multiple applications are running on a single server and each application requires a unique cookie, you must configure the cookie name in each Web.config file for each application.

The default is ".ASPXAUTH". From here link text

Answer 7

I do agree with previous answer, that you should investigate the sessions timing out first!

But regarding cookies: Request cookies are the cookies sent from the client to the server and Response cookies are the ones sent from server, telling the client to save them locally and attach them to the next, and all upcoming until the cookie is outdated, requests to the server.

Cookies have a limit on size and because of their behavior will create an overhead on data sent between server and client on requests, and can of course also be disabled on client side as well.

Answer 8

In answer to your question about copying the cookie from the request to the response, no this is not necessary.

When the cookie is created it can persist for as long as you require.

If it is just needed for the duration of the session then do not set anything against the Expires property. In this case the cookie will be held in the browser memory and served up with each request to you website until the browser is closed.

If it is to persist between sessions the set the appropriate DateTime value against the Expires property. In this case the cookie is written as a file on the client machine and continue to be served up with each request to your website until it's exiry date is reached or it is deleted.

Of course, be aware clients can disble cookies in their browser.

Answer 9

No you do not have to keep resetting the cookie in the response.

Once set that cookie will continue to be sent with each subsquent request.

However I agree with Dominic you should first determine the reason you are unable to maintain the session in the first place.

Some reasons are:-

• The host is using a web garden or a load balancer that does not support session affiliation
• There is an aggressive setting for session timeout on the host
• The host has a problem and is recycling the application pool frequently
• Your client has overly tight cookie settings and is rejecting all cookies (however that would mean your alternative solution wouldn't work either)
• Application logic may be faulty causing Session.Abandon or Session.Clear when it ought not.