>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.