Michel,
Yes it's pretty common for apps to actually have two cookies: One for managing authentication (like Forms Authentication) and one for user identification if anonymous access is allowed. The auth cookie only works when users are authenticated. Depending on the application you might not need to track any information on anonymous users and if that's the case the FormsAuth cookie with the attached user data can be all you need. Most of my apps actually use that.
Either way I typically use a UserState object that contains basic user information like IsAuthenticated, UserId, Name, IsAdmin so I have some of the basic information that I need in each request without having to look up the user record on each hit from the database. I then have a very simple serialization routine that simply splits the string and stores that info in the forms auth cookie data (or its own cookie if an anonymous cookie is required) all encoded and then Base64Encoded. This is super easy and fairly efficient.
+++ Rick ---
>>I think you have to pretty much run with cookies enabled in just about any app except if you're not dealing with anonymous users and you're using Windows Authentication. In all other cases cookies are pretty much required. Especially with AJAX these days old approaches like License Plating are no longer really an option to track a user effectively.
>>
>>However, it's HIGHLY recommended that you limit your cookie usage to one application level cookie that is some sort of ID that points at server side data to identify users. Typically this is a user id backed by some sort of data store that holds user's session/conifguration information. I would even go as far as recommending not to use Session state it can be really resource intentisve and forces a secondary cookie to track the session.
>>
>>I think cookies are pretty much accepted these days as long as they are first party cookies and there's only one cookie. With ASP.NET and FormsAuthentication you can use your authentication as the user tracking mechanism with even the ability to store some often reused data directly in the form's authentication ticket itself. Howevr, that does require that users are logged in so you may still need a secondary cookie if you need to track anonymous users.
>
>Thank you for a very detailed message.
>
>I think you just found my problem. My framework uses two cookies. One that contains some authentication information and one that contains member specific data. As on this site I use both, that might explain why I ran into that situation from time to time. I will adjust my framework to use only cookie. That might turn out to be some very useful thread I just created. :) I will let you know how it runs.
>
>I never use session state as, as you pointed out, it is resource intensive. I also prefer to handle it from the coding infrastructure I have presently.
