Last post May 02, 2019 09:57 AM by Zefek
Apr 24, 2019 09:04 AM|Zefek|LINK
first I want to apology to send new question in Visual Studio General Questions. But I cannot see ASP.NET forum. I would like to ask you if there is someone who solved problem with auth cookie.
We have two IIS servers and load balancer which switch users between these servers. We use Form authentication to log in user. In login there is created auth cookie and it is sent back to browser (client). When user creates request then this cookie
is send back to server and user is authenticate. It works fine. But there is some situation when user is switched to context another user. I don't understand how. User is switched means that user is logged as another user.
I take a long time to investigate it and learn about cookie authentication. I think there must be some place where cookie from another user is send back to different user. But there is one place where auth cookie is send back to client only. This
is login page.
My question is if this behavior could be caused by IIS servers.
Apr 24, 2019 11:01 AM|mgebhard|LINK
This symptom is commonly caused by using static variables to hold data. It's highly unlikely that Forms Authentication is causing this issue as Forms Authentication has been around for a very long time and it's well tested.
Apr 27, 2019 06:56 AM|Zefek|LINK
Thank you. I investigated login process and using user data in application. We use our membership provider because we have more than user/password tuple to login user. I think this is problem. This membership provider is not accessed through Membership static
class but it is accessed directly calling by OurMembershipProvider.GetInstance().GetCurrentUser();. It means our membership provider is singleton. GetInstance mehtod was not programmed as thread safe. This was first detection when I saw it. Second is method
GetCurrentUser. This method read auth cookie, decrypt it and create user instance. This user instance is saved into HttpContext.Current.Items["CurrentUser"]. GetCurrentUser is programmed as lazy, it means if there is object in HttpContext.Current.Items["CurrentUser"]
it is returned without parsing auth cookie. I think it could be problem because I read HttpContext is not thread save. So is it possible that one thread write user object into Current.Items and another thread rewrite it by another user object?
I'm not familiar with HttpContext works with many threads.
Apr 28, 2019 12:44 PM|mgebhard|LINK
So is it possible that one thread write user object into Current.Items and another thread rewrite it by another user object?
Current.Items is not the issue and the construct has has been around a very long time.
The HttpContext belongs to the current request, a thread. You must write code to allow the threads to shared data. I suspect the custom authentication provider design is causing this issue.
Apr 30, 2019 08:33 AM|PatriceSc|LINK
membership provider is singleton
And it stores some state ? So it seems the same state would be shared accross all users ? Not sure what you get but I would always start from User.Identity.Name which is exposed at many places...
May 02, 2019 09:57 AM|Zefek|LINK
I compared standard SqlMemberShipProvider and our MemberShipProvider. Our provider can log in user. It means it can create auth cookie. In GetCurrentUser method auth cookie is decrypted and MemberShipUser is instantied by information from cookie. There was
not access through static MemberShip class. It caused some special behavior, i.e. we know user before login because it writes user into HttpContext.Current.Items …
Our provider implementation was too complex (more than 3000 lines of code and some inheritance is there). I found some static variables which holds user instance in code. I think it could be problem so. I reduce our provider to necessary functions (no more
than 200 lines of code) and convert all static properties to non-static. I hope it can solved this problem.
Second problem is that data entities are written terribly. It means there is use provider GetCurrent method. Problem is this data entities are used from Web Forms application which uses forms authentication by cookie and WebService application when user
is authenticate by user/password send in one request with data together. So it means I don't have any user in this request so I need to store MemberShipUser instance in HttpContext.Current.Items in new solution and GetUser method called by MemberShip class
will return it. In WebService there must be some save method to save it.
I have headache from it. It is very terrible written application in 2008 and our customer doesn't want to rewrite it into some new technology like ASP.NET Core MVC or MVVM. Reason is missing documentation and there are some functionalities which nobody knows
how it works and new application testing time is too expensive for him.
Thanks for your patience. I rewrite login and user management in application much easier and standard way than it is now. It will release to production 07/2019 so then I will to know if it works or not.