ASP.NET User Profile vs using Cookies

Question

I think, in almost all cases user preference data may be stored in a cookie with (almost) equally good results as when the User Profile API is used. Disadvantages of using cookies (for authenticated users) seem to be that a cookie can be deleted or time-out, in which case the user preference data will be lost. For anonymous users, if the preferences data needs to be persisted across sessions then a cookie will have to be used even when User Profiles are used.

So what are some of the biggest advantages/disadvanges of using either User Profiles or cookies for storing user preferences?

Answer 1

Cookies are limited in maximum length and they are using an implementation beyond of your control (after all, they are a feature of your visitors browser). Personally, I dislike relying on unknown third-party implementations I don't have any control over and if I have to, I'm trying to use it in the simplest way possible.

So from where I'm coming from, I would always store the user data on the server and just pass around a cookie pointing to that information.

Aside of not trusting the browser with a potentially big chunk of data (which may be lost, incorrectly stored or not stored at all depending on not only the browser but also, say, some antivirus application or whatever), this has various other advantages:

• You are hiding your implementation from the user: If you store the data in the cookie, it's visible for anybody and can be analyzed or modified at will. This can even lead to users changing cookies to there liking and thus force you into keeping stuff around you probably want to get rid of just because some users are depending on your particular implementation at any time.
• As cookies are stored in plain text, on shared machines, everybody can no longer easily see all the settings the previous user made, nor change them at will.

But the most important point remains the disconnect from not-quite-working browser implementations (just storing small tokens is the common, tested use-case)

Answer 2

Don't forget that one of the biggest disadvantages of using cookies is that they can be copied, so its dangerous to store authentication info on them.

I'm not familiar with User Profile API but I'm guessing it stores the information on the server(?). If thats the case then you could have a problem if you have to many users.

Overall maybe the best solution is to use User Profile if it guarantees the persistence of the information.

Answer 3

Another disadvantage to holding all the preference data in cookies is that all of that data will have to be sent in every request from the client and in any response from the server whenever a change to the data is made. Whilst this may seem like a minor point in the age of broadband it is still an additional overhead. Using the Profiles API meands that the data is held at the server and only a session identification cookie needs to be sent by the browser.

Also, as you stated, for anonymous users if cookies are deleted then the user preferences held in the Profiles DB will no longer be accessible. However this will not be the case with registered users of your website. If they remove their cookies the server will still be able to retrieve their user preferences the next time they log in.

Answer 4

One of the benefits of registering on a site is that it remembers my preferences - if you're storing that information in a cookie on my machine instead of on your server then when I log into your site from another computer, I've got to set all my preferences up again - from a usability point of view, this is fairly bad.

For an anonymous user, storing the prefs in a cookie may seem fairly sensible - you don't know who they are, or whether they will comeback, and as you state, you can't work out from one session to the next who they are - however you'd probably be better off storing some sort of token in the cookie and mapping that to a preferences store on the server.

Also, I've noticed different browsers have different implementations for cookies - for example IE can now receive 50 cookies from one domain (up from the original 20), but it is still limited to a total of 4096 bytes for the entire cookie collection (and previous) - other browsers will support 4KB per cookie, rather than per domain.

Answer 5

Keep in mind that its possible to write a ProfileProvider that persists user data in a cookie, so you can have the best of both worlds if you determine the state you want to persist is appropriate for cookies (size, security, etc).

Answer 6

Actually, you do not need to persist preference data in cookies for anonymous users when using the ASP.NET Profile Provider. Simply store the current UserID (which is some horrible looking session-related string) in a cookie. This becomes the previous UserID on subsequent visits, and then you can just grab the old Profile information and migrate it to the current Profile, or even authenticate them as that old anonymous Profile.