We store two objects in session. Somehow, one of the objects from another user got loaded into a different user's session. The user should have had no access to this particular data, and as soon as they saw it they knew something was very wrong.
We have visual proof of the data that was presented to him, and there is certainly no way it could've happened unless the sessions got mixed up. This is a very scary situation which we can not figure out (we can not reproduce it). The only answer for us is to blame ASP.NET StateServer for mixing the session variables up, which is completely unacceptable and puts us in a bad position.
Our applications are ASP.NET 2.0 apps running on Windows Server 2003 with IIS6, using the StateServer cookieless="false" session mode and FormsAuthentication.
Has anybody else had this problem? How can we resolve it?
We ran into this exact issue in my previous company and took 3 weeks to debug it. ASP.NET was giving a user someone else's session state. It was really impossible to duplicate in a debug environment.
The fix when we found it was just something in web.config. I don't fully remember it, so I spent some time googling. I believe the issue had something to do with output caching. Take a look at this article under "Sessions and Output Caching".
http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (the article is titled Keep Sites Running Smoothly By Avoiding These 10 Common ASP.NET Pitfalls by Jeff Prosise in July 2006 edition of MSDN magazine)
If that sounds like your scenario, then the fix might just be disabling the enableKernelOutputCache option in web.config.
Good luck.
Look for bugs in your own code first - this is by far the most likely explanation. E.g. using static fields or other shared memory such as the ASP.NET cache for user-specific data.
Possible answer - similar isue reported using cookieless session state.
session showing something wrong
Edit - Added
Another possible answer:
An ASP.NET page is stored in the HTTP.sys kernel cache in IIS 6.0 when the ASP.NET page generates an HTTP header that contains a Set-Cookie response
How many times did it occur? Did you check for users using browser back or sending links to each other with session ids?
One way to check for sure about State Server bug is to switch to another session manager, fallback to in-proc if you can or use SQL Server but would be better to find a way to reproduce the bug it first so you could test it.
Could the two crossed users both be using the same cacheing proxy? If so, then one user might see data that was cached for another user if the URLs matched, especially if the proxy isn't well behaved.
Wasn't this the main problem with the Google Web Accelerator project (now discontinued)?
Had this problem, turned out to be an OutputCache attribute on a partial view.
Related
After a lot of reading about EnableViewStateMac and the possibility it will be removed in future .NET Frameworks I still wonder why this is an option to set to false.
I understand you should NEVER set it to false, but who decided it to create the option? And if someone really thought about it, why would one set it to false at all?
Why would you have an option to enable insecurity?
This switch was created long before I joined the ASP.NET team, but I was curious about this myself and spent some time spelunking through the old bug database. As far as I can tell, there are two main reasons it was introduced.
The switch was seen as potentially offering a performance benefit. In an early preview of the .NET Framework (1.0 alpha, really), computing the MAC was indeed slow. This was fixed before 1.0 reached RTM so that the performance difference was negligible. However, the damage was done: the seed was planted in the early developers' minds that there might be some cases where for performance sake the MAC needs to be disabled. This also led to a bunch of MSDN articles which suggested that disabling the MAC improves performance, and I'm still (in 2014!) finding and removing these articles.
In a web farm environment, the <machineKey> needs to be synced. Unfortunately we don't make it easy to generate machine keys securely. So, in the early days of ASP.NET testing, the switch existed to allow testers to do the simple thing for farm deployments rather than the right thing for farm deployments. We're still battling this today, too: most developers use online machine key generators, which are insecure. I'm working with the Visual Studio team to make generating and securing machine keys easier.
At the time, it was believed that the worst possible thing that could happen if the MAC was disabled is that you could XSS the site. This turned out to be an incorrect assessment.
Finally, its removal is no longer just a possibility. It has already been removed in our local source repositories. The next .NET Framework update that we blast out onto the world will have this payload in it, but I don't have timelines for when that might be. We're just sitting on the trigger waiting for the go-ahead. :)
Initially during times of asp the HTML page used to be posted to asp pages which was totally different. This similar coding method is now termed as cross page posting. ViewState is specific to a page so if you try posting an asp.net page to another asp.net page the viewstate would be different. Now in such a situation if you have EnableViewStateMac (which means you want to verify the integrity of viewstate) set the validation would fail and cause an error. So people would disable the viewstatemac so that they can continue to program the old way, and Microsoft continued to provide this feature to have support for the legacy code.
But as you already mentioned this is a huge security risk, opening your application for all kinds of attacks.
I need to have a new session per browser window/tab. I am aware of the fact that ASP.NET assigns one session per process. I am also aware that browsers share this session between all open tabs/windows of the app. However, I need to come up with a way to create a new session for a new tab/window.
Cookieless session-state is not an option also. I already looked at that. I am looking to keep URL's clean.
I looked at the following solutions.
1) asp.net - session - multiple browser tabs - different sessions?. This solutions suggests using IsPostBack property, which is not available in MVC.
2) https://sites.google.com/site/sarittechworld/track-client-windows. This one looks very complex and I don't fully understand the javascript magic that is happening in it. I don't want to put in a solution that I don't understand. Also, I am not fully aware of any security holes that this solution may create.
Can someone point me in the right direction?
The only way to achieve this is to append the session id in the url which is what cookieless sessions are intended to do. Unfortunately you seem to have ruled out this possibility due to the ugly urls it produces.
I've created a NuGet package called ASP.NET MVC Conversational Session. Here you find more information: http://blog.micic.ch/net/asp-net-mvc-conversational-session
I released the first version yesterday. Have a look at the demo code or download the demo solution and let me know if there are things to improve. :)
EDIT: By default: The "identifier" is passed via URL when you use the appropriate extension method in the View. But you can add the identifier on your own. It gives you more flexiblity. (For example when you have links which are not generated via #Html.ActionLink.. etc.)
I've done some searching and haven't found a specific answer. Anyhow, I was wondering how most medium sized ASP.NET based websites cache data so that they don't always have to database look ups for the same data on different pages when running on a web farm environment. I'm aware that you can use a sql server cache, but to me, that defeats the whole purpose of the cache. If I want to use a dedicated server to share cache (and even possible session data), what do most sites use for this? I've done searching and get a lot of 'guesses' when it comes to implementations, but it's really hard to believe that there isn't some standard way of doing this given that there are so many ASP.NET websites out there.
I am aware of AppFabric that seems like it might do the trick, but only runs on Windows server 2008+ and we're currently using 2003. Also, I've checked out NCache but it seems to be a little pricey.
Has anyone implemented a solution that worked for them? Database lookups can be quite painfully slow when 1000+ users are hitting your site simultaneously.
Thanks in advance!
Might want to take a look at HttpContext.Cache and HttpRuntime.Cache
You can get your information from the database then create datasets (or dictionaries, or whatever you want) and then store those in cache to be referenced site wide.
You can even specify how long you want the cache to persist. And when it expires the next request for that data will go to the database and recreate your cache.
I'm in the process of disabling asp-sessions completely from a site. Its quite a large and complex site, but we're not using the session object programatically anywhere, so I'm just curious if anyone know of any "hidden" issue that may occur if you disable sessions? Viewstates, ajax etc? We're using Dundas components for charting and mapping, but they seems to work ok when running on our test servers.
Check the session events in global.asax. There's one for start and one for end. Make sure nothing is happening there, and you should be be good to go. Assuming the Session type is inproc.
I recently had a discussion on another forum with another developer and the topic was Code Reuse in ASP.NET. The stated scenario was that he needs to update code frequently on Production servers during server uptimes, and this results in Session getting reset for all users. He is avoiding putting shared code or classes into the App_Code folder or precompiled DLL's into the Bin folder because any updates will also refresh the Session.
The solution he has come up with is to put his shared code into UserControls and reference them wherever required. This enables him to update only the UserControl files which would be recompiled dynamically on next request without forcing a Session restart. Note that the Usercontrols are not intended to have any UI, they probably only house some business logic.
I tried to convince him against this because it felt intrinsically wrong to me - but I could not provide any hard facts to support my claim that this was a very bad way of doing things. The only thing I could think of is that it violates the principle of separation of business logic from UI. Am I grossly mistaken or are there concrete reasons why this should not be done? Links or examples would be helpful.
Note: Using out-of-process Session state is not an option at present, nor have they been able to decide on scheduled downtimes. Also, since this is a site under active development, they don't seem to be using any sort of professional deployment model yet.
Thanks in advance.
Edit: Additionally, it would be helpful if someone could clarify exactly why the Session restarts in the above mentioned cases.
It does seem like an unusual approach, and persistent session is the obvious answer. Assuming that reasons not to use persistent session are legitimate, sometime you just have to go with whatever works. I'd make a point of clearly documenting in the source files the unusual use of usercontrols and live with it.
To answer the why does session get reset edit. With in process session all the session data is in memory as part of your application. Various changes to the web site (e.g. web.config and others I don't recall off the top of my head) cause the application to restart wiping out all current state in your application. Persisting to SQL or the out of process session state server would allow the application to reset and lose any state without affecting the session data.
It sounds like the main problem is that he's updating production code too frequently. Other than that, UserControls seem like a perfectly reasonable place to put business logic, especially if you have a good naming convention for them or can put them in a common folder.
May i ask, why isn't out-of-process session state an option, really?
Since this guy seems to put in so much effort to get around this "problem", wouldn't he be better off looking at better solutions? out-of-process session state is the only good solution.
I'll agree with Dennis, there are really no issues moving from inproc to the state server. Not sure what your dev/deployment platforms are, but they should include a session state service - start that up, change your web.config, and the problem is solved.
it's a clever (and ugly) solution to a common problem
The main problem is the architecture of such system; the code that needs to be updated can be put on a different service outside his web app, his code behind can then call these services, and the services can be updated when needed without affecting the web app
Every base has been covered already, but I really hate bad practices like this. If the guy can't simply change to a state server to fix the problem that he has, then he doesn't really deserve the help. What would happen if he put his class in the root folder of the project and compiled it independently? Either way, I would think this guy is a bad developer for not thinking about scalability, and not planning for downtime. What I'm guessing is he doesn't have a development environment available. Tsk tsk tsk.
As an answer to your question, as stated by everyone else, put the code in a user control, and document well.