What can cause ASP.NET FormsAuthentication cookie issues other than disabling cookies?

Question

People are reporting problems registering with one of our ASP.NET sites. When I check the IIS logs, it looks like the FormsAuthentication cookie is not cached by their browsers after logging in.

I don’t think it is as simple as “the user has set that the browser does not accept cookies” because:
a) If cookies do not work for their browser at all, they would never have received as much as possible - an ASP.NET session cookie seems to work fine, for example.
b) These are generally not those users who would even know how to disable cookies.

Therefore, I think it should be something else. What problems can cause ASP.NET FormsAuthentication cookies to stop working, besides the fact that users simply set browsers to reject cookies?

edit: For example, this answer to another question suggests that sometimes FormsAuthentication cookies are deleted because they are too large - maybe someone can shed some light on this?

edit: cookie FormsAuthentication for one of our sites - 233 bytes - is this a bit more? Can less be done? Maybe this will help.

edit: I noticed that the code uses FormsAuthentication.SetAuthCookie() and Response.Redirect() instead of FormsAuthentication.RedirectFromLoginPage() - could this be related?

Answer 1

I had a similar problem (not with an authenticated cookie, but with a sticky loadbalancer file), because the server did not have the correct time / time zone configuration, so there were cases when the cookie expiration date was higher than the current time by user machine.

see here: How do cookie and cache values ​​expire?

hope this helps

Answer 2

Is it possible that a user accesses your web server through 2 different domains? For example, if I go to www.foo.com and receive a cookie for authentication, and then redirect to www.bar.com, the request sent to www.bar.com will certainly not contain the cookie set at www.foo.com.

This problem will also occur if you set the cookie to htp: //login.foo.com and then redirect to htp: //content.foo.com. However, I believe that cookies can be set using a wildcard so that it applies to * .foo.com.

Edit: intentionally mistakenly spelled “http” so that this answer doesn’t have real clickable garbage links. :)

Answer 3

If your site operates in a web farm, you may need to install the same machine keys on all servers, or if the user switches the server, they may not be able to decrypt the authentication ticket.

The difference between RedirectFromLoginPage() and SetAuthCookie , followed by Response.Redirect() , is that the former also works if cookies are disabled (it actually uses the query string parameter to track authenticated users).

Answer 4

Could it be that the web server name or part of the DNS name contains an underscore?

eg:

www2_http.mydomain.com

I remember that I had this problem at some stage of development, where sessions would not behave regularly. Removing the underscore from the machine's domain name resolved the issue for me.

considers

Answer 5

Do you use multiple domains to talk to the same web application? Remember that cookies are domain specific, www.mydomain.com <> www.mydomain.net <> my.domain.net.

Beat in the dark, do you have machine keys in your web.configs?

Answer 6

There is a downtime timeout - do they log in and then do nothing and then try to access the site again? You can check it out. And see if the timeout is set as a sliding timeout (for example, 20 minutes after the last request) or a fixed timeout (for example, 20 minutes after logging in). I think overclocking timeout is not the default setting.

Answer 7

Try the following steps.

http://blogs.msdn.com/b/rahulso/archive/2007/01/17/troubleshooting-cookies-a-case-study.aspx

I wrote this a long time ago, but if you follow it closely, the chances are high that you will find the root cause.

Isolating the root cause is key here. Solving the problem will be quite simple if you understand why this happens in the first place.

Rahul

www.dotnetscraps.com