In my website, when a web page is idle for more than 5 minutes, then that page is not working until I refresh. The following error occurs:
Error:
Sys.WebForms.PageRequestManagerServerErrorException:
Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
I'm already using EnableEventValidation="false" ViewStateEncryptionMode="Never" ValidateRequest="false"
But, nothing is working for me.
Although it's an old question, I will answer anyway because it might help someone else.
So I had this problem in the past few days, and I realized that I started getting this error after I configured my cookies as HttpOnly and Require SSL:
</system.web>
<httpCookies httpOnlyCookies="true" requireSSL="true" />
</system.web>
Turns out that I just forgot to configure Visual Studio to open the SSL URL of my website. So as long as it opened the regular Url, the cookies couldn't be sent, and that what caused the error.
In order to change the default Url, you simply need to figure out what is your SSL url: Click the project on solution explorer and press F4 (not Right Click -> Properties) and over there you'll see SLL URL under the the Development Server section. After that, go to the project properties page (Right Click -> Properties) and in the Web tab, put the SSL Url as the Project Url.
Make sure all the servers on the cluster are using the same encryption key.
This sometimes happens if you are doing a postback from a form which has an action pointing to a different page.
Related
I have a problem with my project Asp.net mvc 1.0, with .net framework 2.0. My application is hosted on a IIS 7.5. My authentication form looks like this:
<authentication mode="Forms">
<forms protection="All" loginUrl="~/Account/LogOn" timeout="60" cookieless="UseUri" />
</authentication>
<httpRuntime executionTimeout="1000" maxRequestLength="600000" />
<sessionState mode="InProc" cookieless="UseUri" timeout="60">
</sessionState>
When a user connects to the webpage, he receives a session id which is stored in the URL. When I connect to my webpage with the default UserAgent (in every browser, Chrome/FF/IE) everything works fine. When I override the browser UserAgent and try to connect with the User agent XXXXXXXX.UP.BROWSER, I receive an infinite redirection loop to address
http://<IP>_redir=1
But when I connect to the default webpage IIS - the user agent doesn't matter and everything loads fine, so it must be a problem with the specified UserAgent and my Application. I tried to find any filters for that XXXXXXXX.UP.BROWSER UserAgent but there aren't any. When I studied application lifecycle I tried to find the differences between good connection and wrong connection and found that functions which are NOT executed are:
Application_AcquireRequestState
Application_PostAcquireRequestState
Application_PreRequestHandlerExecute
Application_PostRequestHandlerExecute
Application_ReleaseRequestState
Application_PostReleaseRequestState
Application_UpdateRequestCache
Application_PostUpdateRequestCache
and another clue I found is that there is no Session in "wrong" connection - Session object is null.
To sum it up: The connection to my application web page with a specified user agent makes an infinite redirection loop, probably because of the lack of the session ID. What could be the problem ?
EDIT: I discovered that User Agent that contains "UP.Browser" is related to mobile. When I changed cookieless to "UseCookies" everything works. Why option "UseUri" doesn't work for mobiles?
EDIT2 : /admin -> my webpage hosted on specified IP address.
Good connection :
Wrong connection:
Sorry, I don't know how to make these images bigger.
http://msdn.microsoft.com/en-us/library/aa479315.aspx
So you're putting two different values into the URI, one for session and one for forms, which would probably create a lengthy URI:
"The principal limitation of this feature is the limited amount of data that can be stored in the URL. This feature is not targeted at common browsers such as IE, since these do support cookies and do not require this feature. The browsers that do not support cookies are the ones found on mobile devices (such as phones), and these browsers typically severely limit the size of the URL they support. So, be careful when you use this feature—try to make sure that the cookieless string generated by your application is small."
My guess is that the key to the infinite redirect loop is this functionality:
"// Step 5: We can't detect if cookies are supported or not. So, send a
// challenge to the client. We do this by sending a cookie, as
// well as setting a query string variable, and then doing a
// redirect back to this page. On the next request, if cookie
// comes back, then Step 3 will report that "cookies are
// supported". On the other hand, if the next request does not
// have any cookies, then Step 4 will report "cookies not
// supported".
SetAutoDetectionCookie();
Redirect(ThisPage + Our_auto_detect_challenge_variable);"
Unfortunately, this sounds like a bit of an architecture rethink, as it's probably going to now matter what the full path to your site is and you may have to drop automatic handling of forms authentication.
As you said the issue is for mobile browsers, I think this issue is limited to the devices(MOBILE) where the cookies are not supported and the Size of the URL increases and mobile browser severely limit that size, as mentioned in the MSDN reference article above.
My solution was to change User Agent containing "UP.Browser" to something else using rewrite rule. Everything works fine ;)
Edit: I found another clue.
In mobile browser - these with user agents containing "UP.Browser", it was necessary to add slash at the of the address.
In conclusion:
Everything works fine for user agents not related with "UP.Browser".
User agents containing "UP.Browser" needed address like:
http://addr/controller/
I don't know why it is necessary. Any ideas?
I'm getting the following error while redirecting one page to another web page:
"the page was not displayed because the request entity is too large.".
The page from which I'm redirecting to another page contains a huge amount of data, so basically I know the cause of the issue.
However, I'm looking out for a working solution for this. Secondly, when I researched this issue I found such kind of problem generates when any large file gets uploaded.
But I'm not uploading any large file, its just the page itself contains large data. Prompt solution will be appreciated.
I think this will fix the issue if you have SSL enabled:
Setting uploadReadAheadSize in applicationHost.config file on IIS7.5 would resolve your issue in both cases. You can modify this value directly in applicationhost.config.
Select the site under Default Web Site
Select Configuration Editor
Within Section Dropdown, select "system.webServer/serverRuntime"
Enter a higher value for "uploadReadAheadSize" such as 1048576 bytes. Default is 49152 bytes.
During client renegotiation process, the request entity body must be preloaded using SSL preload. SSL preload will use the value of the UploadReadAheadSize metabase property, which is used for ISAPI extensions
Reference.
I got it working by doing the following
Go to IIS.
Click on the server name
In the features (icons), chose the configuration editor.
Click on the dropdowns on the top with Settings
Traverse the path system.webServer -> security -> requestFiltering -> maxAllowedContentLength and set it to 334217728. (Then hit enter and then apply on the top right).
You can also restart the webserver for good measure.
After that I could upload my 150k database to phpymyadmin.
I also set post_max size to 8000 in php.ini in programs/PHP/phpversion/php.ini
It may be overkill for the sizes but it gets the job done when you've got big files.
For me, uploadReadAheadSize did not fix my issue.
I changed both of these settings in my asp.net web.config and finally the file uploaded for me:
<system.web>
<system.webServer
<httpRuntime executionTimeout="999999" maxRequestLength="20000" requestValidationMode="2.0" /> <!-- 20 MB -->
</system.web>
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="20500000" /> <!-- 20.5 MB - making it match maxRequestLength to fix issue with uploading 20mb file -->
</requestFiltering>
</security>
</system.webServer>
Another possible cause is an Authentication setting. Within IIS7,
Select the site under Default Web Site
Select Authentication
Select Windows Authentication and enable. Disable all others.
While Windows Authentication is still selected, click on Advanced Settings in the Actions pane.
Make sure Extended Protection is on Accept and check the Enable Kernel-mode authentication
I had the same error and the above fix did not work. I was only on HTTP (localhost)
However this fixed the 413 error
Set-WebConfigurationProperty -filter /system.webserver/security/requestfiltering/requestLimits -name maxAllowedContentLength -value 134217728
I did the above but still had no joy.
What fixed the problem for me was also upping the request limits:
- Select site in IIS manager
- Click "Edit feature settings" from right hand menu
- Insert 200000000 for "Maximum allowed content length"
In my case, the error occurred when downloading a file.
The reason was, that I had a code that explicitely sends an HTTP 413 to the client in an (erroneous) case.
(See here for details).
So be aware of the fact that setting an HTTP response code 413 in your code (or in a library that you are using) also can generate the OP's error message.
Using the C#/.NET Google+ sign-in quick start project, I'm hitting problems with IIS6. Here are the steps I followed:
downloaded the project from Github
modified the index.html and signin.ashx files to contain my Client ID and Client Secret
running the project on my machine (using the built in web server for Visual Studio 2010) works fine
published to Windows 2003 server with IIS6
added "index.html" as a default document for the web site
set the web site to use an app pool configured for the 4.0 .NET framework
attempted to access the page from Chrome
Accessing the site with no page specified on the URL (https://myserver.com/gplussample/) brings up the Google+ signin button. This works great and I'm taken to the page with my profile photo, circles, etc.
However, when I click the "disconnect" button, nothing happens. Using Chrome DevTools to examine the process, I see this error:
POST https://myserver.com/gplussample//disconnect 404 (Not Found)
The problem is the //disconnect - there's no page name (I believe it should be signin.ashx, as that's what works when I'm running the app on the dev web server with Visual Studio 2010).
I then attempted to access the site with a page name specified:
https://myserver.com/gplussample/signin.ashx
That results in a blank page and again, looking at the Chrome DevTools, I see a 400 Bad Request error for the .ashx handler. I searched and searched for solutions for .ashx handlers and "bad request" errors, with no success in this particular case.
Thinking IIS6 was the culprit, I published the site to an IIS7 instance.
With no page name specified on the URL (http://localhost/gplusoriginal/), I encountered the same error with the "disconnect" button - no action and a 404 error.
When I changed the URL to http://localhost/gplusoriginal/signin.ashx, I received this error:
Could not create type 'GPlus_ServerSideFlow.Signin'.
Again, back to Google and checking on .ashx handlers and issues with IIS7. I found a post about the web.config and specifying the handler there, so I tried that.
<system.webServer>
<handlers>
<add name="GPlus_ServerSideFlow.Signin" path="*.ashx" verb="*"
type="GPlus_ServerSideFlow.Signin" resourceType="Unspecified" />
</handlers>
</system.webServer>
Adding this snippet to the web.config resolved the "could not create type" error, but resulted in another 400 Bad Request error.
So, my questions are: What has to be done with II6 or IIS7 to get this sample project working? Are there additional steps in configuring IIS that need to be completed? Or something missing from the project code?
Thank you
The way that the sample works is that the RESTful endpoints are intercepted by an ashx handler, signin.ashx.cs. The handler can't be directly addressed so routes are setup in global.ashx.cs to map endpoints (/, /connect, /disconnect, etc) to that route handler.
As the sample ships, it assumes the built-in web server running on the root port. When moving to IIS, you need to change the path matchers from Equals to EndsWith in order to match the virtual directory you are deploying to:
// Redirect base path to signin.
if (context.Request.Path.EndsWith("/"))
{
context.Response.RedirectPermanent("signin.ashx");
}
// This is reached when the root document is passed. Return HTML
// using index.html as a template.
if (context.Request.Path.EndsWith("/signin.ashx"))
{
Apologies for the delay on this... but hopefully that fixes it! This fork of the C# starter has the changes in it, tested with IIS, and this update may end up getting merged back into the official sample soon.
I am developing a website, At the moment when i run it off my local host every thing works fine.
I have uploaded this website to fireFTP and can now access my website online.
The website does not preform the same as when hosted on local host and i cant find the errors as my website does not break.
I would like to do some testing and am wanting to know how to display an error message??
I would like to display the error message like this:
But with a custom message like, "code stepped into method writeToSpreadSheet".
This way i could find where my code gets to and pin point whats going wrong.
You need to enable show detailed error messages in IIS settings, see the link below for a short tutorial about how to do it.
IIS7 : HOW TO enable the detailed error messages for the website while browsed from for the client browsers?
Add this lines in web.config inside so you dont have
to touch the IIS configuration:
<customErrors mode="On">
<error redirect="error404.html" statusCode="404" />
</customErrors>
Change the error404.html for your desired html page.
When some page is not found user will be redirected there
Running the ASP.NET webforms run the application works fine. When the application is idle for 4 to 5 minutes, it is giving this error:
Validation of viewstate MAC failed. If
this application is hosted by a Web
Farm or cluster, ensure that
configuration specifies
the same validationKey and validation
algorithm. AutoGenerate cannot be used
in a cluster.
How can this be solved?
This free online tool: http://aspnetresources.com/tools/machineKey generates a machineKey element under the system.web element in the web.config file.
Here is an example of what it generates:
<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />
Once you see this in your web.config, the error itself suddenly makes sense.
The error you are getting says
"ensure that configuration specifies the same
validationKey and validation algorithm".
When you look at this machineKey element, suddenly you can see what it is talking about.
Modifying the pages element under the system.web element may not be necessary with this in place. This avoids the security problems associated with those attributes.
By "hard coding" this value in your web.config, the key that asp.net uses to serialize and deserialize your viewstate stays the same, no matter which server in a server farm picks it up. Your encryption becomes "portable", thus your viewstate becomes "portable".
I'm just guessing also that maybe the very same server (not in a farm) has this problem if for any reason it "forgets" the key it had, due to a reset on any level that wipes it out. That is perhaps why you see this error after an idle period and you try to use a "stale" page.
See http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
This isn't your problem but it might help someone else. Make sure you are posting back to the same page. Check the action on your form tag and look at the URL your browser is requesting using Firefox Live HTTP Headers.
I ran into this because I was posting back to a page with the same name but a different path.
Modify your web.config with this element:
<pages validateRequest="false"
enableEventValidation="false"
viewStateEncryptionMode ="Never" />
Any more info required, refer to the ASP.NET Forums topic