What could cause ASP.NET FormsAuthentication Cookie problems apart from cookies being turned off?

Question

People are reporting having trouble logging into one of our ASP.NET sites. When I check the IIS logs, it looks like the FormsAuthentication cookie is not being cached by their browsers after they log on.

I don't think its as simple as 'user has set their browser to not accept cookies' because:
a) If cookies in general weren't working for their browser, they'd never have got as far as they have in the process - the ASP.NET session cookies seem to be working OK, for example.
b) These generally aren't the kind of users who would even know how to turn cookies off.

So I think it must be something else. What sort of problems can cause ASP.NET FormsAuthentication cookies to stop working, apart from users simply setting their browsers to reject cookies?

edit: For example This answer to another question suggests that sometimes FormsAuthentication Cookies get dropped because they are too large - perhaps someone can shed some light on that?

edit: the FormsAuthentication cookie for one of our sites is 233 bytes - is that a bit big? Can it be made smaller? Maybe that would help.

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

Answer 1

Is it possible the user is accessing your webserver via 2 different domains? For example, if I go to www.foo.com and get an authentication cookie, then redirect to www.bar.com, the request sent to www.bar.com certainly won't contain the cookie set by www.foo.com.

This issue would also happen if you set the cookie at htp://login.foo.com, then redirect to htp://content.foo.com. However, I believe the cookie could be configured using a wildcard, so that it would apply to *.foo.com.

Edit: deliberately misspelled "http" so that there aren't actual clickable garbage-links in this answer. :)

Answer 2

There is an idle timeout--are they logging in, then not doing anything for a while, then trying to access the site again? You might check that. And, see if the timeout is set to be a sliding timeout (e.g., 20 min after last request) or a fixed timeout (e.g., 20 min after login). I think the sliding timeout is not the default setting.

Answer 3

If your site runs in a web farm you might need to set the same machine keys on all servers or if the user switches server it might not be able to decrypt the authentication ticket.

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

Answer 4

Try the following steps.

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

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

Isolation of the root cause is the key here. Fixing the issue will be pretty simple once you figure out why it is happening in the first place.

Rahul

www.dotnetscraps.com

Answer 5

Could it be that the webserver name, or part of the DNS name contains an underscore?

eg:

www2_http.mydomain.com

I remember having that problem during some development stage, where the Sessions would not behave regularly. Removing the underscore from the machines domain name resolved the issue for me.

regards

Answer 6

I've had a similar problem (not with the formsauthentication cookie, but with a sticky loadbalancer cookie) because the server didn't have a proper time/timezone configuration, so there were cases when the cookie expiration date was previous than the current time in the users machine.

see here: http://stackoverflow.com/questions/2262530/how-do-expire-values-work-for-cookies-and-caching

hope it helps

Answer 7

Are you using more than one domain to talk to the same web application? Remember that cookies are domain specific, www.mydomain.com <> www.mydomain.net <> my.domain.net.

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