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

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: How do expire values work for cookies and caching?

hope it helps

Answer 2

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