viewstate errors logging in with Internet Explorer but not

viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

Post here for help with installing or upgrading mojoPortal pre-compiled release packages. When posting in this forum, please provide all relevant details. You may also want to review the installation or upgrading documentation.

If you have questions about using the source code or working with mojoPortal in Visual Studio, please post in the Developer forum.

Post here for help with installation of mojoPortal pre-compiled release packages

When posting in this forum, please try to provide as many relevant details as possible. Particularly the following:

What operating system were you running when the bug appeared?
What database platform is your site using?
What version of mojoPortal are you running?
What version of .NET do you use?
What steps are necessary to reproduce the issue? Compare expected results vs actual results.

You may also want to review the installation or upgrading documentation.

If you have questions about using the source code or working with mojoPortal in Visual Studio, please post in the Developer forum.

This thread is closed to new posts. You must sign in to post in the forums.

4/15/2014 11:40:22 AM

lilleyt

Total Posts 21

View Posts

viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

I've just encountered this, so I haven't done any troubleshooting yet, but it's serious enough that I'm posting here first.

I just upgraded my production server to mojoPortal 2.4.0.2. Everything went fine.

However, I did not test actually logging into the site with IE. This is IE 11 we're working with. I encountered the same error coming from two different systems, one of which was a VM with a vanilla IE 11 install and no antivirus or plugins. The machines are on the same subnet as the server with no kind of proxy or firewall between them, and the login capability was working just prior to the upgrade. I also cleared the cookie cache on the browser to be sure.

I was able to log in using Chrome just fine and did all of my work from there.

The error in the log is here.

I did some googling and could not find anyone experiencing the same issue. Any pointers appreciated.

My version info is as follows:

mojoPortal Version 2.4.0.2 MSSQL
Operating System Microsoft Windows NT 5.2.3790 Service Pack 2
ASP.NET Info v4.0.30319 Running in Full Trust

Ted

4/15/2014 11:45:29 AM

Joe Audette

Total Posts 18439

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

There are some known asp.net issues with IE 10 and IE 11 that have been fixed by windows updates. If the web server has all of the windows updates there should be no problems. So my best guess is that the web server is not up to date on windows updates.

Hope that helps.

Joe

4/15/2014 4:10:33 PM

lilleyt

Total Posts 21

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

No joy after updating, unfortunately.

Looks like it's time to move to server 2012.

5/6/2014 3:57:12 PM

lilleyt

Total Posts 21

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

So I've gotten around to installing Server 2008 R2, with all updates, and moving my mojoportal install over to the new machine, all the setup steps, yada yada.

Unfortunately, it hasn't solved the viewstate issue. I'm still getting invalid viewstates from IE 10 and 11 when attempting to log into the new site. I know the configuration is correct because Chrome and Firefox as well as old versions of IE sign in correctly. I've also verified that there is nothing wrong with the layout, since I've read online that some people were having this issue due to multiple form tags being on the same page.

One interesting data point is that running the same site in Microsoft Web Matrix on my Windows 7 desktop does not exhibit the signin issue with IE 11 (I haven't tested 10). So apparently the issue is localized either to the server itself or IIS. The IIS version is 7.5.

I've googled quite a bit to no avail, so the next step I'm going to take is to inspect the requests using fiddler and see what may be different. I could really use any suggestions others have as well.

Thanks.

5/6/2014 4:06:50 PM

Joe Audette

Total Posts 18439

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

I would install .NET 4.5 if you have not already, then check windows update again for any new updates. On a fully patched machine with the latest .NET I have never been able to produce this problem though I have seen it on machines that were not up to date with windows updates.

5/8/2014 11:09:12 AM

lilleyt

Total Posts 21

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

Thanks for the response Joe.

I'm a bit mystified since 4.5.1 is installed on the server (with no pending updates) and I'm still having the problem.

mojo and iis report the application pool version as 4.0, but apparently that's correct from all of my googling, as 4.5 is an in-place upgrade which supposedly means it doesn't change the reported version to the applications. At least I've read that in several places.

I'm going to have to dig a bit deeper on this.

5/8/2014 11:22:36 AM

lilleyt

Total Posts 21

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

An additional datapoint:

I can successfully log in with the default site on mojoportal so long as I'm using "localhost" as the hostname. When I switch to the proper hostname (same site), it fails with the mac viewstate error.

5/8/2014 11:46:41 AM

lilleyt

Total Posts 21

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

Looking at the behavior with fiddler, I see the following pattern:

IE, when connecting to localhost, and Chrome in general do correctly post the login credentials from the /Secure/Login.aspx page in the form of post parameters, with the redirect parameter set to the root url "/". The post goes through successfully and the browser is redirected to the root page, signed in.

IE, when connecting to any name other than localhost (irrespective of whether the name is configured for a site in mojoportal), does _not_ submit the login credential parameters in the post, however it does post the redirect parameter. The browser is redirected to the root page, at which point it submits a post to _that_ page, this time including the login parameters from the login page. I'm presuming the viewstate error is because the post must also be submitting the viewstate from the prior login page, which won't validate because it doesn't match the viewstate of the actual page it is posting to.

I don't know what's causing this behavior yet.

5/8/2014 12:00:02 PM

Joe Audette

Total Posts 18439

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

you could try putting enableViewStateMac="false" on the <pages element in Web.config but it would be best not to do that if possible and you really should not need to do that. Fully patched servers that I'm working with don't exhibit this problem.

viewstate errors can also happen if the user clicks the button to postback before the page is fully loaded in the web browsers. possibly something in the skin could be funky or causing the page load to be slow, so i would try other skins to eliminate that possibility.

on a web farm it is important that all nodes have the same machinekey otherwise viewstate errors can result, but you seem to be working with one server so that should not be the problem, that problem would also not be browser specific.

really the browser specific problems should all be solved by updated browser definition files that should have come from windows update

if there is a proxy server between your web browser and the server, it is also possible that is causing the problem

5/8/2014 12:02:53 PM

Joe Audette

Total Posts 18439

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

I would try other client machines with IE to see if the problem is specific to the client machine based on what you are saying you see in fiddler which seems very strange.

5/8/2014 2:55:23 PM

lilleyt

Total Posts 21

View Posts

Re: viewstate errors logging in with Internet Explorer but not Chrome after 2.4 upgrade

Thanks for the suggestions. That's a fairly complete list from my research.

I'm failing to fix this, so I'll be backing off from it for a while and giving it another go later.

What I know which doesn't fix it:

tried from three separate clients - consistent failure for IE 10 and 11, never a problem for other browsers
page is fully loaded before clicking the button, I've made sure so it's not that
no dueling form tags in my layout
switched to one of the default artisteer layouts shipped with 2.4, no luck
not a cluster/farm, just a single IIS (tested from localhost for the most part)
no web proxy
machine and decryption keys are set in Web.config and recognized by IIS
viewstatemac=false doesn't work either, although I wouldn't use that anyway since although some sources say to do it, it conflicts with MS sources which say its a serious security hole, more than just csrf, and should absolutely never be done in production
running "aspnet_regiis.exe -i" from the .net directory and rebooting not only doesn't work, but apparently the exe isn't upgraded by 4.5 since it breaks 4.5 sites
using installer "repair" function and rebooting doesn't work
uninstalling 4.5.1, reinstalling through windows update, installing all updates and rebooting doesn't work either (although it reverts the app pool to .net 2.0, so you have to set back to 4.0 manually)

As you can see, I've tried a few avenues. There may be one or two more tricks I can pull out of my sleeve, but not until I've thought of them. My next step will probably be a fresh 2.4 install by itself to determine whether something in my directory is causing the issue.

Cheers.

You must sign in to post in the forums. This thread is closed to new posts.