Validation of viewstate MAC failed

Jan 10, 2008 at 4:50 PM
It is really serious. I got the following error. It started when I set up my ABout-Me page as a Front-Page, then click login/logout several times...you get this error... any idea?

Server Error in '/blogs/myBlog' Application.
--------------------------------------------------------------------------------

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
Exception Details: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

Source Error:


No relevant source lines


Source File: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\blogsmyBlog\599e262e\987c480\AppWeb_toqaorof.8.cs Line: 0
Coordinator
Jan 10, 2008 at 8:30 PM
The issue was fixed earlier today and can be downloaded from the Source Code tab
Jan 16, 2008 at 3:32 PM
Hi Mads,

I do believe the newest version (1.3.0.8) fix the problem. I test it again and again in my local development environment (Windows XP).
But as I run it in my server (Windows 2003). I still get the same error. right after you set up a page as Home Page...you can not log in.
Jan 16, 2008 at 8:02 PM
Edited Jan 16, 2008 at 8:04 PM
I get the same error. It happens when you set a new page as the default page . . . you will receive the error on "Sign In" and "Sign Out" . . . but only if you click those links on the new page when it is set as the default. You can still browse to another page and click the "Sign In" "...Out" pages without the error.
Jan 23, 2008 at 4:52 PM
same error on me with new version updated.. confirmed happens only in new pages... sign in and sign out are both compromised.

Any help from support team ???

Thanks a lot.
Jan 23, 2008 at 4:52 PM
Edited Jan 23, 2008 at 4:54 PM
same error on me with new version updated.. confirmed happens only in new pages... sign in and sign out are both compromised.

Any help from support team ???

Thanks a lot. ..... sorry for repeat the entry.... the mouse got nervious !!!
Jan 24, 2008 at 3:31 PM
same problem here and only with the new pages
Feb 7, 2008 at 2:20 PM
Is there any news on this? This is a pretty anoying bug. Is there a temporary workaround?
Feb 12, 2008 at 9:45 AM
I have the same error.
Any help from support team ???

Feb 12, 2008 at 12:25 PM
i have the same error and need help too.
Thx
Feb 12, 2008 at 12:25 PM
Edited Feb 12, 2008 at 12:26 PM
i have the same error and need help too.
Thx
sorry for the double post :)
Feb 12, 2008 at 5:50 PM
I had the same problem. Modifying the following web.config line solved the issue:

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">

changed to

<pages enableSessionState="false" enableViewStateMac="false" enableEventValidation="false">
Feb 13, 2008 at 12:10 AM
I try your solution.. but is not the perfect behaviour. Now I dont get any MAC validation error but the SignIn link dont go anywhere, stay un the same page all the time, even if I go directly to login.aspx page and I get logged in when I try to log out also I stay in the same page with to Log process.
So... I'm planing to go next step and modify the LogIn control changing it by a custom control checking manually the authentication status and redirecting to login page.... then, if still the same problem, means the situation cames from the membership provider...
I will let you know...
Feb 13, 2008 at 6:48 AM
I also tried the solution and I have the same problem:
I dont get any MAC validation error but the SignIn link dont go anywhere, stay un the same page all the time, even if I go directly to login.aspx page and I get logged in when I try to log out also I stay in the same page with to Log process.

Feb 28, 2008 at 3:40 PM
I was having the same problem. Here's what I did to work around this issue without sacrificing security:

Replace:

<li class="page_item"><asp:LoginStatus runat="Server" LoginText="Sign in" LogoutText="Sign out" EnableViewState="false" /></li>

With:

<li class="page_item">
<asp:LoginView ID="LoginView1" runat="server" EnableViewState="false">
<AnonymousTemplate>
<a href="<%=Page.ResolveUrl("~/login.aspx") %>" rel="nofollow">Sign In</a>
</AnonymousTemplate>
<LoggedInTemplate>
<a href="<%=Page.ResolveUrl("~/login.aspx?logout=true") %>" rel="nofollow">Sign Out</a>
</LoggedInTemplate>
</asp:LoginView>
</li>

And to login.aspx:
if (Request.RawUrl.Contains("logout=true"))
{
FormsAuthentication.SignOut();
Response.Redirect("default.aspx", true);
}



It's not pretty, but it works. Let me know if anyone comes up with a better solution!
Mar 24, 2008 at 11:22 AM
Edited Mar 25, 2008 at 9:55 AM
The file that you need to edit is: site.master. If you have a other skin then standard you need to go to themes/ then your theme and site.master. If you are using BlogEngine.NET 1.3.0.0 there is no "<li class="page_item">" tag, it's only this tag: <asp:LoginStatus ID="LoginStatus1" runat="Server" LoginText="Sign in" LogoutText="Sign out" EnableViewState="false" /> replace that tag with:

<li class="page_item">
<asp:LoginView ID="LoginView1" runat="server" EnableViewState="false">
<AnonymousTemplate>
<a href="<%=Page.ResolveUrl("~/login.aspx") %>" rel="nofollow">Sign In</a>
</AnonymousTemplate>
<LoggedInTemplate>
<a href="<%=Page.ResolveUrl("~/login.aspx?logout=true") %>" rel="nofollow">Sign Out</a>
</LoggedInTemplate>
</asp:LoginView>
</li>

And do not forget to edit the login.aspx file. It works for me, big thanks for the fix!
Apr 20, 2008 at 3:35 AM
Has there been an official fix for this problem? I was able to get rid of it by changing the Server.Transfer call to a Response.Redirect() call in the default.aspx.cs OnLoad(...) event.

Anyone know if that's a bad idea?

Thanks.
Jun 9, 2008 at 1:07 PM
From what I can tell that's ok.  But what do I know?!?

Just an FYI that I've also experienced this issue and would love to know when/if a "real" solution occurs.  In the meantime, I have used the solution above (changing Server.Transfer to Response.Redirect in default.aspx.cs).