One of the sites I maintain relies heavily on the use of ViewState (it isn't my code). However, on certain pages where the ViewState is extra-bloated, Safari throws a "Validation of viewstate MAC failed" error.
This appears to only happen in Safari. Firefox, IE and Opera all load successfully in the same scenario.
While I second the Channel 9 solution, also be aware that in some hosted environments Safari is not considered an up-level browser. You may need to add it to your application's browscap in order to make use of some ASP.Net features.
That was the root cause of some headaches we had for a client's site that used the ASP Menu control.
My first port of call would be to go through the elements on the page and see which controls:
Will still work when I switch ViewState off
Can be moved out of the page and into an AJAX call to be loaded when required
Failing that, and here's the disclaimer - I've never used this solution on a web-facing site - but in the past where I've wanted to eliminate massive ViewStates in limited-audience applications I have stored the ViewState in the Session.
It has worked for me because the hit to memory isn't significant for the number of users, but if you're running a fairly popular site I wouldn't recommend this approach. However, if the Session solution works for Safari you could always detect the user agent and fudge appropriately.
I've been doing a little research into this and whilst I'm not entirely sure its the cause I believe it is because Safari is not returning the full result set (hence cropping it).
I have been in dicussion with another developer and found the following post on Channel 9 as well which recommends making use of the SQL State service to store the viewstate avoiding the postback issue and also page size.
http://channel9.msdn.com/forums/TechOff/250549-ASPNET-ViewState-flawed-architecture/?CommentID=270477#263702
Does this seem like the best solution?
Related
I am trying to scrape some web page but because HtmlWeb.Load() is so fast (I believe) it blocks me and asks me to do a captcha. Sometimes I can load it and other times I can't.
I'm wondering if there is any way to slow that down (maybe htmlweb has some built in methods/properties to do it? or maybe there's a way to limit the resources for my app so it purposely runs slow?). If that's not possible is there an easy-ish way to bypass captchas? Any tips/help would be greatly appreciated, thanks.
<p>
As you were browsing, something about your browser made us think you might be a bot. There are a few reasons this might happen, including:
</p>
<ul>
<li>You're a power user moving through this website with super-human speed</li>
<li>You've disabled JavaScript and/or cookies in your web browser</li>
<li>A third-party browser plugin is preventing JavaScript from running.</li>
</ul>
You think it's because you're loading a single page too fast, but that's not at all what they're telling you. You're switching between pages far too quickly to be a human. And/Or, as I suspect your app may be doing, you're not loading JavaScript in your program. And/Or you're not handling cookies.
Any or all of these three things can be signs of bot activity. Which you are by the way. So they throw a captcha up because they don't want bots trying to crawl their site. You're not going to bypass captcha easily for sure, so your best bet is to address the actual issues they lay out in the message.
Slow down the time between page loads to something more realistic for humans browsing. You might still get snagged if you're going over their entire site in a non-human fashion though.
Handle whatever cookies they're trying to set so that you look like a normal user. A few successive no-cookie hits to the site from the same IP might not set off a flag, but a few dozen to hundreds will.
If those don't work, perhaps they're really insistent on JavaScript elements loading on their site, and you'll have to find a way to make your app run the JavaScript pieces so that it doesn't look like you're a bot.
But to sum it up, you're a bot, and their system is working as intended.
I've got a very bizarre situation. It appears that, when I load a webpage to my browser,
multiple threads (at least 2) are starting up. The app loads and runs fine on a
Windows XP box, but when I try to run it on my Windows 8 laptop it would seem that
more than one startup event is taking place and causing all kinds of collisions. This
is happening with both Firefox and IE.
To verify this behaviour, I placed a static int within a class, checked it to see if its
value is greater than zero, throw an exception if it is, then increment the int.
Of course, the exception is thrown.
What's very weird about this is that there is no multi-threading/multi-tasking involved
within my app.
When I "touch" the DLL for the webpage (rebuild it), it renders the webpage properly,
but the source for the webpage ("right click" > "View Page Source") has the source
for the unhandled exception webpage, with the message for the exception that my code
throws when the thread count is greater than zero.
I've tried creating a new project, then linking the code to it (Add Item ... Ad As Link),
then building it. It didn't do any good.
The Win XP system has IIS 6 with .NET 4.0, and the Win 8 laptop has IIS 7 with .NET 4.0.
Language is C#.
The truth is that I'm pretty much clueless about IIS.
I hope someone smarter than I am (which isn't saying much) has an idea as to what
is going on.
It appears that, when I load a webpage to my browser, multiple threads (at least 2) are starting up
Maybe onetime initializations. I doubt that every request causes an additional two threads to stay around.
it would seem that more than one startup event is taking place
That's normal This event fires for each instance of HttpApplication being created. This is basically a design error in ASP.NET. They thought that pooling HttpApplication instances and assigning one of them for each request was a good idea. It would have been better to have a singleton per AppDomain. Write this yourself. Like that:
class MyGlobalAppState { ... }
static Lazy<MyGlobalAppState> state = new Lazy<...>(StateFactory);
Be aware, that Lazy<T> stores any exception and just rethrows it. This causes your app to be permanently broken in case StateFactory throws. It will never recover without pool restart. This is a design error in Lazy<T>. Find a way to deal with that.
but the source for the webpage ("right click" > "View Page Source") has the source for the unhandled exception webpage
Some browsers re-GET the page to view the source. This can be annoying or handy.
It is hard to tell what is causing this behavior but as others suggested try to use Fiddler or any other http tracing tool to see what requests are sent.
Also, Win XP should be running IIS5.x while Win8 should be running IIS8.
By default IIS8 AppPool should be running with the integrated pipeline, which may behave differently. I would try changing the AppPool to use the Classic pipeline to see if it makes a difference.
I am having a problem but I am not sure where.
I have created a website which uses Angular, this might not be pertinent but then again it might be. Of the many features of this site one of them is the ability to upload a file and then get back a response. The response is a simple amount of JSON. The only browser I have to get this working with at this point in time in IE8. avoiding incoming thrown objects - I have tried everything to change this fact, but it is what it is.
I have gotten the site to mimic AJAX uploads by submitting a form and having the response redirected to an iframe. In fact I am using a module that does most of this for me.
So far all this works better than you would believe in IE8. I know right? Unbelievable!
But… there’s always a but…
I need to get this page working when running in a Webbrowser control in a winforms project. I get as far as uploading the file which happens successfully. My REST service gets it, saves it, and returns the correct response. When debugging I can even see that the response is available. But for some reason the load method for the iframe is never called. The iframe which I have made visible on the page is never populated with the JSON.
Again this works when running in IE but not when in the webbrowser control. I get no errors and have breakpoints and debugger statements everywhere. It’s like the response falls in a crack and is ignored.
Would anyone have any suggestions as to why this is happening? crossing fingers
Sorry for the delay I have been ..., well there is no adjective for how busy I have been.
The answer lied in the module that was chosen to help upload files. It worked for IE 8 straight up, but not when running in the web browser control. The module was dynamically binding an onload event to an iFrame which was also being dynamically create to handle the post back. Anyone that has worked with IE and needed to upload files might know of this method. This worked in IE8 but not in the web browser control. We modified it to add the onload event when the iFrame is created and that fixed the issue.
I have a new message page that can only be accessed if you are replying to a message or you click to message a user (unless of course you guess the URL). The cancel button currently will send you back to the previous page you were on using javascript:history.back().
I'm wondering if this is the best practice or if I should be using something on the server side to set where the cancel button takes you.
I took a look at this similar question: Does using javascript:history.back(); have any unknown issues?
I don't understand the cache problem mentioned in that post or the javascript being disabled because the site has a lot of javascript that this feature would be the least of the concern if the user does not have javascript. I'm also not too worried about the user not having a page to go back to because as I said, this new message page can only be accessed by clicking on a button on a site unless you guess the URL or copy the URL into a new window.
I'm wondering if there's any other issues on doing it one way or another.
Thanks!
Well, one issue you did mention was when the user types in the URL? Maybe we're crazy, and/or hate buttons! Joking aside, using history.back is mainly frowned upon due to its static nature (who knows if there is a page to go back to).
What the guy is trying to say in the link you provided about caching is that, for example, say you had a sign in page. If you hit your button using history.back, the browser would use a cached version of the webpage, and in turn, clear out anything you filled in. It would also show that you weren't logged in on the users end.
If you do have server side logic. I think your best bet in this case would be to just put in an windows.location.href to your previous page. That way, this issue is resolved, and you know exactly where the user is going.
I have a C# .NET 3.5 application with an embedded web browser. The browser is designed to point to remote sites (Rather than anything local). Everything works fine, but when the page is slow to respond this causes my entire application to become unresponsive until the page is loaded.
I don't mind the browser being unresponsive while it does its thing, but the application going too is far from ideal.
Is there a good way to prevent this? Would it be beneficial to run the WebBrowser on a seperate thread - that's a bit beyond my skillset right now and I don't think the WebBrowser control really likes multithreading? But I can learn if needs be.
See the answer #2 on this question for a solution on how to run it on a separate thread: BackgroundWorker and WebBrowser Control
You might as well read answer #1 too, it explain the behaviors you are seeing (WebBrowser control blocking UI thead).
As it happens I found that the root cause of this was my application running as administrator. Exactly the same issue was seen when using Internet Explorer - as such, I've simply rewritten the bits that required admin privileges so I'm now no longer seeing the original issue.
this happened only on win7;I use fiddler2 to Monitor HTTP/HTTPs traffic .I find embedded web browser to visit this web:http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?50ff94e72ac1a75c;the solution is follow:http://support.microsoft.com/kb/2730040/en (Method 2 or Method 3).you can try it.other u can use .net framework4.0,then u haven't this problem.