views:

69

answers:

3

I'm looking for some guidance with respect to cookies in ASP.Net MVC (or just cookie handling in general). I have been storing authentication information about users who authenticate via a form login in a cookie. This is working great, but I now need to store a little more information in the cookie. This additional information is not really "authentication related" so I'm hesitant to store it in the authentication ticket. Is there a better practice for storing extra information. Is it possible to set multiple cookies (and if so is that a good/bad practice)? Other things I should be considering here?

Here is the current code I'm using to set the authentication ticket and wrap it in a cookie:

private HttpCookie GetAuthCookie(AuthToken authToken)
{
    var authTokenXml = serializationService.Serialize(authToken);
    var authCookieString = FormsAuthentication.Encrypt(
        new FormsAuthenticationTicket(
            0,
            Keys.AuthToken,
            DateTime.Now,
            DateTime.Now.AddMinutes(AppSettings.SessionTimeoutMinutes),
            true,
            authTokenXml));
    var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, authCookieString)
                     {
                         Expires = DateTime.Now.AddDays(AppSettings.AuthCookieExpireDays)
                     };
    return cookie;
}
+1  A: 

There is a size limit to how big a cookie can be, 4096 bytes. After this, you may need to chunk the data into several cookies if wanting to continue to store in cookies. Obviously you now have the added complexity of reading from all to reconstruct your authentication ticket + data and, if one cookie was not sent with the rest, it may have some dire consequences.

Have you looked at using a different session store? That's effectively what you're using the cookie as here and unless it's related to authentication and needs to be available in the processing pipeline before session is accessible, I'd be inclined to look at putting this in session. You could use an out of process session store such as a database if not wanting to store session in process.

Russ Cam
@Russ Yes, I have been considering using SQL Server Session State as an alternative to the cookie approach. The extra data I need to store is small (probably 20 characters), so it shouldn't add too much overhead on the wire or in terms of cookie size. I was sort of hoping to avoid using a database just to store this additional info, unless it is truly the better practice, and this is why I asked the question here. Thanks for your feedback.
Paul
if it's only 20 characters, it's probably not doing any harm in the cookie. If it is this small though, using the in proc session could also be a good fit. Maybe try both ways and see which is preferable?
Russ Cam
A: 

You should not put anything but authentication data in authentication cookie. Asp.net usage of cookies is much the same as in any programming platform for web. You can set as many cookies as you like and store in them whatever you want. Some examples:

http://www.cookiecentral.com/faq/

http://stephenwalther.com/blog/archive/2008/07/08/asp-net-mvc-tip-15-pass-browser-cookies-and-server-variables-as-action-parameters.aspx

http://www.asp.net/general/videos/read-write-and-delete-cookies-in-aspnet

Marko
+1  A: 

Rule of thumb: store in the cookie only the minimum (usually this is the user id) and use this minimum to fetch the rest from your datastore every time you need it. If you are happy with the performance you can stop reading.

If you realize that there are too many queries to your datastore you could use session or cache the results of your queries.

Darin Dimitrov