Viewstate Validation Fails During Checkout
Posted: Tue Jun 08, 2010 10:52 am
We created an AC store for a client quite some time ago, and they recently had a customer report a viewstate validation error during the checkout process when they are selecting their shipping method.
Our client was pretty concerned, and their customer was slightly annoyed. Rightly so. So I added some code to the global.asax file to email me the error information on viewstate errors. For a couple weeks I didn't see anything at all, then I got flooded one day with like 40 or so in about 3 minutes. After inspecting the reports, and doing some research on the IP address, I determined this was a bot from china. The errors were also from most of the category pages, after clicking the search button. So I just let it go, probably not an issue. This happened again about a week later, it was the same ip, so I didn't bother to look into it.
Recently I received about 10 new reports which turned out to be from the user that had originally reported the issue. Unfortunately, as is always the case, I wasn't able to reproduce the issue. The error reports weren't much help either. I checked the user's history in the store and followed her path through the store the best that I could, and I still didn't have any issues. While I was doing this I noticed that after she failed to select a shipping method several times she returned to the homepage and then went back to her cart and checked out without issue.
We have made some minor changes to this section of the checkout. Instead of selecting a shipping method via the radio buttons, and clicking continue. A user now selects "Prepaid" or "Collect", and then they are presented with a filtered list of radio buttons based on their selection. It has been a while since this code was written, and the user was able to checkout after returning to the homepage, so I'm thinking (hoping) this is not the issue.
I have searched through the forums, and I haven't been able to find anything quite like this issue. I did find two threads that were interesting though...
viewtopic.php?f=42&t=12749&p=54998#p54998
This post mentions large viewstates being truncated by some browsers.
viewtopic.php?f=42&t=13765&p=59112#p59171
This post mentions that gigantic viewstates may be due to your website still being in debug mode.
And trust me, I really slapped my forehead when I read this. And again when I checked the web.config file and found that it was indeed still in debug mode. (Probably should have known that from the error screen shots the user sent over lol) So I have changed this, and I'm hoping it was the cause of the issue. But of course, we won't know until the error happens again.
So, in closing, I guess I don't really have a question. I'm just looking to see if anyone can confirm my suspicions, or call me a fool and point me in a better direction. Either is welcome, and much appreciated.
Thanks,
Chris
Our client was pretty concerned, and their customer was slightly annoyed. Rightly so. So I added some code to the global.asax file to email me the error information on viewstate errors. For a couple weeks I didn't see anything at all, then I got flooded one day with like 40 or so in about 3 minutes. After inspecting the reports, and doing some research on the IP address, I determined this was a bot from china. The errors were also from most of the category pages, after clicking the search button. So I just let it go, probably not an issue. This happened again about a week later, it was the same ip, so I didn't bother to look into it.
Recently I received about 10 new reports which turned out to be from the user that had originally reported the issue. Unfortunately, as is always the case, I wasn't able to reproduce the issue. The error reports weren't much help either. I checked the user's history in the store and followed her path through the store the best that I could, and I still didn't have any issues. While I was doing this I noticed that after she failed to select a shipping method several times she returned to the homepage and then went back to her cart and checked out without issue.
We have made some minor changes to this section of the checkout. Instead of selecting a shipping method via the radio buttons, and clicking continue. A user now selects "Prepaid" or "Collect", and then they are presented with a filtered list of radio buttons based on their selection. It has been a while since this code was written, and the user was able to checkout after returning to the homepage, so I'm thinking (hoping) this is not the issue.
I have searched through the forums, and I haven't been able to find anything quite like this issue. I did find two threads that were interesting though...
viewtopic.php?f=42&t=12749&p=54998#p54998
This post mentions large viewstates being truncated by some browsers.
viewtopic.php?f=42&t=13765&p=59112#p59171
This post mentions that gigantic viewstates may be due to your website still being in debug mode.
And trust me, I really slapped my forehead when I read this. And again when I checked the web.config file and found that it was indeed still in debug mode. (Probably should have known that from the error screen shots the user sent over lol) So I have changed this, and I'm hoping it was the cause of the issue. But of course, we won't know until the error happens again.
So, in closing, I guess I don't really have a question. I'm just looking to see if anyone can confirm my suspicions, or call me a fool and point me in a better direction. Either is welcome, and much appreciated.
Thanks,
Chris