views:

29

answers:

2

I'm creating an HttpCookie, setting only the name and value and not the expires property, then adding it to the response. Simple enough. The cookie is created (but not persisted) as expected. The problem is when the session changes for some reason (like the website was rebuilt, or I rebuilt my app when debugging) then the cookie stays around. I want the cookie to be valid for only the original session it was created on.

According to MSDN it says: "If you do not specify an expiration limit for the cookie, the cookie is not persisted to the client computer and it expires when the user session expires."

I guess I don't know exactly what "session expires" encompasses. I figure the cookie gets deleted after 20 min when the session expires. But should the cookie get deleted if the session it was created on doesn't exist anymore for any number of reasons? The only time I've seen the cookie get deleted is when the user closes all browser windows and opens a new one.

If this is all true, I may have to store the original session id ("ASP.NET_SessionId") in the cookie, then check it against the current session id, if they're different, then delete the cookie or create a new one.

Here's the code (the only difference between my cookie and the one in the MSDN examples is I'm storing multiple values in the cookie):

private void SaveValuesToCookie(string[] names, string[] values)
{
    HttpCookie cookie = new HttpCookie("MyCookie");

    for (int i = 0; i < names.Length; i++)
    {
        string name = names[i];
        cookie.Values[name] = values[i];
    }
    Response.Cookies.Add(cookie);
}

private string GetValueFromCookie(string name)
{
    HttpCookie cookie = Request.Cookies["MyCookie"];
    if (cookie == null)
        return null;

    return cookie.Values[name];
}
+2  A: 

The only time I've seen the cookie get deleted is when the user closes all browser windows and opens a new one.

And that is exactly what MSDN means when it says the cookie will be deleted when the session expires. Unfortunately, I believe this isn't consistant across browsers anyway, so it's not much use to anyone.

You should always set an expiry date on Cookies.

If this is all true, I may have to store the original session id ("ASP.NET_SessionId") in the cookie, then check it against the current session id, if they're different, then delete the cookie or create a new one.

I hate to say it but this isn't going to help you either. The .NET Framework likes to recycle session IDs, so you can't guarantee it will be different.

Bad news out of the way, I would advise you to reconsider what you're trying to do from an architectural standpoint.

Restarting the app is something that happens entirely on the server; cookies are something that happen entirely on the client. While the client will talk to the server, it is purely a Request/Response relationship, the server cannot communicate events such as an application restart to the browser.

If you want to store a value somewhere which is only valid for the lifespan of a server session, why not store it in Session rather than in a Cookie?

pdr
The reason I don't want to store it in the session (which is how I was originally doing it) is I need a secure cookie that is only passed if using https. I don't want to secure the entire session because that would mean the whole site would have to use https. So in my sample code I left out this part in SaveValuesToCookie(): cookie.Secure = true;
goku_da_master
If you're storing things in the Session, they're not passed to the client, so they're about as secure as can be. They only live in memory on the server. The client just sees the session ID as a cookie which gets sent back to the server and the .NET framework retrieves the session data based on that. If the session gets killed, the data is lost which is normally a risk, but not if you want to invalidate the data on session/app restart.
pdr
A: 

I'm aware of all that, but it's not secure enough for our clients needs. The session can still get spoofed or injected. See: http://msdn.microsoft.com/en-us/magazine/cc163730.aspx#S9

Looks like I'm left to creating an expired secure cookie separate of the session, and refreshing the expiration date when I can (ie when the user accesses certain pages).

(btw, this is the same goku_da_master, I'm just now registered :))

goku_da_master
If a session cookie can be spoofed, so can your custom cookie. The only way to stop that is to stop the data travelling across the wire unencrypted -ie. use SSL. That will protect both your cookie and the standard session ID making your cookie superfluous.
pdr
Yes, that is what I meant by "secure cookie". Setting the Secure property on the cookie so it only travels when https is used.
goku_da_master
btw, not sure how to mark the post as answered now that I'm registered. Thanks for the help.
goku_da_master