I have seen a few ways to detect if javascript is enabled. I have a unique situation. The Global.asax handles all thrown errors
protected void Application_Error(Object sender, EventArgs e)
{
//email development team
}
Recently, I have had issues with people disabled javascript on their machines. These are corporate machines and they are not allowed to do this. I could add some javascript detection to the master page, but I dont know how I can get this into the "catch all" method above.
What can I do to detect if javascript is enabled on the client in this scenerio?
You can Use javascript to change the value of hidden field in the page's onload event.
If you get new value on postback, then javascript is enabled
Well, I don't think you need general js detection for your particular task. I would advise you to add a <noscript> tag, and put an image into that tag. If anyone requests that image, then you might want to do that error logic you were talking about.
I'll try to find some resource that collaborates that browsers don't fetch what's inside <noscript> tags if scrips are enabled.
EDIT
See this previous stackoverflow post for more info. It's intuitive that this must be true, but it's nice to have more than one opinion behind this.
Oh, I just saw that you were going with the ajax + wait n seconds approach.I would strongly advise against that, seeing as how you might easily get false positives - this may happen when the user quickly navigates away from the trapped page or some kind of temporary network delay occurs.
And although you are not interested, this approach has the added benefit of graceful degrade. The booby trapped image might as well show the user how to turn scripts on. :)
This gives a thorough explanantaion for what you require
http://www.codeproject.com/KB/aspnet/JavaDetectService.aspx
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 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've got a modal dialog created using ModalPopupExtender. There is an UI created in it using Webservices and a JQuery Templates. There is also a hidden ASP.NET button which is called from the javascript using the __doPostback() technique. The javascript hides the modal popup and __doPostback is called on the button (which is inside of the ModalPopupExtender)
I use this technique to pass some parameters are from the javascript. The server-side event handler does some processing and transfers to a page (in some cases, back to itself)
This works fine when the page it transfers to is a different one but if it transfers to the same page, the postback happens over and over again until the stack blows.
How do i stop the postback from re-occurring when I postback to the same page. I guess it doesn't happen the first time around because it posts to a different page and the postback is invalidated.
Code samples are difficult to provide as it's a fairly complicated system and it's difficult to break it apart.
It sounds horrible I know, all I want to do, however, it to call a server side function from javascript with some variables. Is there a better way to do this?
Well, you're posting back, so you have server-side control over your markup. Just stick your javascript that does the repost in a container and in the case that the page posts to itself, hide that container so it's not loaded into the page....
That or you could do client cookies or a querystring param. Both might be wonky.
With out a code sample I can only speculate and hopefully point you in the right direction.
When you transfer to a new page the old page (and therefore the javascript on that page) passes out of scope and therefore does not continue to execute. If, however, the page is reloaded and the condition that invoked the __doPostback continues then you have created the circular reference that causes your problem. Before you invoke __doPostback, but while you are still on the client, you need to clear whatever condition might be causing the chain of events.
If you can not uncover what is invoking your event chain then you might consider that instead of transferring back to the same page transfer to a new page (bounce.aspx) which in turn invokes a response.redirect BACK to the page so that it is not a Postback when it is being reloaded, but a fresh instance of the page. (Yes, this is a kludge, but it might be an effective stop gap...)
Cheers,
CEC
Thanks for the responses. I think i've found the solution.
In the server-side callback I was doing this:
setupPage();
Server.Transfer("mypage.aspx", true);
changing it to this:
setupPage();
Server.Transfer("mypage.aspx");
fixes the problem.
SetupPage() stores all of the data in hidden fields and I assumed that preserving the form state would be necessary so that this resided after the transfer. This doesn't seem to be the case as all of the setup I've done in the page before the transfer seems to still be present.
Odd or perhaps I'm misunderstanding something fundamental about .NET
Edit - Yes, I do misunderstand a lot about .NET. It makes my head hurt sometimes.
Thanks for the help
I have an ASP.NET (C#) page that has a long load time (like 2 minutes). The user is presented with a little animation and a "please wait" message. If the user accidentally loads this page, they need to wait for it to load.
My question is: Is there a way to stop the page load?
Thank you
If you want to stop the server side processing then its a tricky operation. Generally once a request is made that page is rendering on its own independant of other thigns going on. What you would probably need to do is re-engineer that page to check at regular intervals whether a stop command has been issued and abort whatever it is doing at that point. The stop flag could be put in session and should be cleared out after the stoppage.
You may also need to consider how to properly identify the right one to stop (in case there is more than one running). This could be done by returning a unique ID that can be used in part of a call to the "abort" page.
My approach though rather than this complciated rigmarole is to make efforts to stop the user from making this accident. Possibly make whatever link they are clicking pop up an alert saying "the following page will take several minutes to render, do you wish to continue" and then hopefully you will effectively be aborting the page request before it is even made.
I should note that I've never tried to do this sort of thing before so there may be easier ways to do it but this is how I'd probably think abotu going about the problem.
Try window.stop() in JavaScript.
I have an asp.net page
when Loading this page it creates a Thread to do some thing
My Question is :
How to kill this thread when the user close the page ?
I have tried with "onUnload" event
but it just works with javascript function (as I know)
and we can't use asp.net code in javascript function
Do You have a way to help me ...
thanks a lot
Edit:
It 's difficult to explain what I am Trying to do.. The asp.net page must show a message to the user and this message must appear directly without refreshing so I was trying to use a thread which listen wait the message and then run an AJAX code to show the message ..
You can't. The browser and the codebehind (the C#) live in different worlds, and once the Page Lifecycle completes (shortly after RenderComplete), the server is done with the request.
It sends the generated HTML to the client and never looks back.
In the onunload event in javascript, you could send an AJAX request to the server to tell it that the user is leaving the page, but that would be highly unreliable, and if you depended on that exclusively to kill threads you would have a major problem on your hands.
Generally, what you're trying to accomplish would be better accomplished another way - so as others have said, let us know what you're trying to do and we'll give suggestions.
You can do this with PageMethods which works with Ajax
First you catch the onunload event on your script page :
body onunload='javascript:PageMethods.UnloadForm();'
then u enable PageMethods on the scriptManager AJAX you have to add to your page :
asp:ScriptManager ID="ScriptManager1" EnablePageMethods="true"
runat="server"
after, you create your PageMethods Code-behind method in C#:
[System.Web.Services.WebMethod]
public static void UnloadForm()
{
// your stuff
}
Hope this will help you.
My actual pb is that Onunload event is generated without closing my page cause of an AJAX timer. But if you don't add a timer, you shouldn't have this pb.
There is no request sent when the page is closing, so right out of the box, the answer is no. However, you have a few options.
One is to send an XmlHttpRequest (Ajax call) from the javascript onUnload event to a WebMethod.
Another is to execute code at the next beginning of the next pageload, which would cover cases besides those in which the user leaves your site for another or closes their browser.
Finally, there are server-side events you can use for, say, session expiration.
What is it exactly that you're trying to do? Maybe we can help come up with a better way to accomplish it.
Just curious: what kind of threaded process are you running? To your question, the only place you're going to be able to capture the event of the browser being closed is in Javascript... you could make an ajax call back to the server to kill whatever thread you've got running for the session, but as others have said, this isn't reliable.
In short there's no direct way to do what you're wanting to do. The best you could hope for is to hook the Sesion_OnEnd event.
It is a poor coding practice to start a worker thread that is dependent upon a page closing for its cleanup as you have little control over what happens on the client browser. Perhaps you could re-think the architecture of this, or at least expound on what this worker thread is actually doing so a better solution can be recommended for that.
If the work that the worker thread is set up to do has a clear path to code completion, the garbage collector will handle the cleanup and there is no cause for concern. If your using a thread from the thread pool to perform your background task via the QueueUserWorkItem construct, then the thread will make itself available for use again in the pool once the work is completed, and you have nothing to worry about as long as you ensure proper disposal of unmanaged resources if any.
As Mike pointed out in a comment, you should really set up a web service that some JavaScript on the page can poll periodically - this would then go and interagate the queue, check for messages, and if it finds one, display a message to the user.
This site has a function very similar to that when you are answering a question - it has a "Heartbeat" javascript call that polls the server looking for new answers - if it finds some, an orange message bar appears at the top of the page telling you there are new answers, and would you like to view them?