I know there are a lot of questions on this topic and I have read them all.
I'm using IIS8, .Net 4.5.
Users randomly get an invalid viewstate error, I can't figure it out. Once this happens the only way they can get back into the site is to clear browser cache.
In my web.config I have:
<system.web>
<machineKey validationKey='....key here' decryptionKey='....decrypt key is valid here' validation='SHA1'/>
<!--<hostingEnvironment shadowCopyBinAssemblies="false" />-->
<authentication mode="None" />
<compilation targetFramework="4.5.1" />
<httpRuntime targetFramework="4.5.1" />
...
</system.web>
I'm running on a virtual private server, and I've yet to find a viewstate larger than 9kb.
My application pool is set to restart at 3:00am, once per day.
My page uses update panels, maybe the user is clicking 'back'? But I've seen it happen just visiting the page with no clicking back.
One thing I noticed is I have 3 different sites using the same application pool identity, but the application pools are seperate. There is no machine keys in machine.xml, but only in my web.config.
A couple of possibilities to investigate:
Update panels are changing form field values (which are what is used to compute ViewState), then the page gets POSTed back to the server, where the new values make validation fail. See this post
You have caching enabled (perform a trace of HTTP headers - make sure you don't have dev tools open) which is causing invalid ViewState to be generated w/ UpdatePanel gumming things up.
Are you using Server.Execute anywhere? (see above link for same)
(less likely) Does your "Virtual Private Server" get migrated to different hardware (perhaps without you knowing it)?
Related
We have a .NET Framework web app where we use .ASPAUTH cookie and ASP.NET_SessionId for authenticated user. Our Session.Timeout is set to 60 minutes in the IIS hosted web.config file.
Recently I follow the recommendation of OWASP top 10 to prevent possible information exposure by Disable caching for response that contain sensitive data.
I did this by adding the following in the Web.config file of the web app.
<httpProtocol>
<customHeaders>
<add name="Cache-Control" value="no-cache, no-store" />
<add name="Pragma" value="no-cache" />
<add name="Expires" value="0" />
</customHeaders>
</httpProtocol>
The very next day I start getting call from some users (not all) that they got redirect to the log out page by simply clicking on links in our web application. So I did what naturally comes to me is to roll back that change and off course that complains went a way gradually.
This puzzle me, as I don't know how http response caching directive could lead to invalidating a user session and log them out. Even though I see the issue went away, there is no way for me to confirm that it was due to my roll back of these header values.
I know the Pragma and Expires are from Pre HTTP 1.1 so I plan to add the following back in and see if I have the log out issue again.
<add name="Cache-Control" value="private, max-age=3600, must-revalidate" />
Do you think they are related? I researched around and all I could come up is the cache control really affect how often the user request resource from server. One factor I don't have control over is can something on the user's browser end that when combine with this Cache-Control directive can destroy their authenticated session?
Update: I see this refers briefly at this resource. However, they don't really go into the details.
I have uploaded my application to live server published code into iis my tab doesn't works on live,tab gets post back on the local, # gets appended automatically at the end of the url unable to postback on the server which causes the postback working to stop.
Look for JavaScript errors on your page. If there are, the tab will not be able to execute its JS logic, so it will act as an ordinary anchor and add the hash to the URL.
It is often the case that webresources do not load on your production server because of permissions. Check these two articles for more info on troubleshooting that:
http://www.telerik.com/help/aspnet-ajax/introduction-troubleshooting.html
http://www.telerik.com/help/aspnet-ajax/introduction-web-resources-troubleshooting.html
You will, most likely, need to let your user access webresource:
<location path="Telerik.Web.UI.WebResource.axd">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
Also, you can try using the CDN to avoid loading resources from your server: http://www.telerik.com/help/aspnet-ajax/scriptmanager-cdn-support.html. If you have it enabled already, then you may not have connection to the cloud where the scrips come from, so you can consider disabling it.
I'm using MiniProfile to try and figure out why my MVC site is taking a long time. It looks like the 'Find' method is where the time is being spent. I have read a couple things on this and most people seemed to suggest that it was due to having <compilation debug="true" .. > set in the web.conf. I can confirm that in the following example the debug is not set (my compilation looks like the following):
<compilation targetFramework="4.0">
...
</compilation>
No where is debug mentioned. But yet, my find calls are taking upwards of three seconds :S
Any suggestions on how I can figure this out? (Note: I am running on an Azure production server. I have RDC'd into the system to confirm that the pushed web.config does not contain the debug="true").
If this is the first request coming to your website after publishing or after the AppDomain has been brought down by IIS it is normal that the Find method takes a long time. It will then cache the location for this view and on subsequent requests it should be much faster. Try Ctrl+F5ing in your browser on the same url.
Also try explicitly setting debug="false" in your web.config.
I am getting this error, and I know what causes it. There are many causes, but in my case, the issue is that the machinekey differs from server to server (in the web farm) and therefore when it jumpes from machine to machine, it can't decrypt viewstate and/or cookies . I've since fixed this issue, however, there are some users still left with a cookie on their machine, written with the old machinekey, and they are getting this error. I need a good way to handle this error, log them out and then redirect back to the login page. I've tried putting an exception handler in global.asax in Application_error, but this doesn't seem to fire for this error. There are other errors that happen, and I've filtered to catch only this error (by looking at the exception). I have customErrors 'on' in the web.config. How do I do this?
There are a few ways to resolve this issue. The best overall solution is to set the encryption and decryption keys explicitly in the machine.config of each server:
<machineKey validationKey="JFDSGOIEURTJKTREKOIRUWTKLRJTKUROIUFLKSIOSUGOIFDS..." decriptionKey="KAJDFOIAUOILKER534095U43098435H43OI5098479854" validation="SHA1" />
Another option is to disable encryption of the ViewState altogether, but you will lose some security benefits by doing this:
<pages viewStateEncryptionMode="Never" />
Lastly, you can disable the validation:
<pages enableViewStateMac="false" ... />
I have something strange going on with our session state.
Our ASP.NET C# application has a session timeout of 10 min, but it seems to be losing session state when redirecting between pages.
So, we set out session value, and redirect to the next step,
Session["temp"] = "somevalue";
Response.Redirect("page2.aspx");
At the top of page2, we check the session value, and if it's not there, redirect back to the start (the code below is the first on Page_Load):
if (Session["temp"] == null)
{
Response.Redirect("start.aspx");
}
The issue is it keeps on doing this redirect, even though the session should not have timed out.
I have checked the config file, and it has a machinekey, as I have been informed that this can sometimes causes issues if it's not there.
Is there something else that could be causing us to lose the session?
Depending how your session's configured, cookie problems can cause you to lose session. As can switching domains / switching between http and https.
And as an aside, if you're connecting over a mobile connection, all sorts of horrible things can happen to your cookies...
Disabled Coockies may be issue. You can also create brand new application (with default web.config without any change) with single page and test it. This will tell you whether the problem is application specific or server specific.
try to add to system.webServer -> modules section in web.config next lines:
<remove name="Session" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />