Ok, the first time this bug / misuse of the FormsAuthentication.UserData issue bit me, it cost me wayyyy too much time to get to the bottom of it. It just bit me again, and this time cost me a few hours while I racked my brains to remember what it was that I discovered the last time I fought this in a different application. I remembered there was some truly enlightening thing I found out last time, but couldn’t find notes or comments about it. So now it goes in my blog, and hopefully (if it bites me again a year from now in another application where I may have already included code that could cause it to appear) I will remember that I bloged about it and will save myself a little time.
The problem is that the UserData string of the FormsAuthentication class can only contain about 1200 bytes of data. The problem really has to do with the actual cookie size limit, but it is a sneaky problem.
I don’t think it is documented anywhere in the SDK that the UserData string should not exceed about 1200 bytes. And normally, when you are utilizing the string it is used to persist a user’s roles with the FormsAuthentication ticket. So, when you build the app, you may have a user in a few roles with short names like “admin”, “user”, etc. All is fine. Over time things happen. Other people modify your code, and seeing as UserData is already holding some data, another developer might put more stuff in there. Or overtime, users of the application might create some pretty complex security scenarios with lots of long role names. As silly as it may be to stick that much data in the FormsAuthentication ticket, and I think we all would agree that we would never do that, the point is that you can. And if you do, nothing “blows up”, no exceptions, no real indications that anything is wrong. However, your FormsAuthentication process will stop working properly. Some people will keep getting redirected to a login page because the FormsAuthentication ticket won’t be able to derserialize properly during the authentication process. But no exceptions are thrown!
Conclusion – If you find yourself ever writing data in the FormsAuthentication.UserData string, always, always, always make sure that you add code that prevents this usage from growing into something silly. Because trying to find why some people can no longer login is not very silly.