This question sort of extends my other question on robots and captcha. I did what everyone recommend (thanks everyone!), however is it at all possible to detect a robot on the server first? For Example (Once again, I will use Stackoverflow as a reference): Sometimes when I ask a question, Stackoverflow comes back asking me to verify if I am human.
However, sometimes it does not.
How does Stackoverflow do that, because that is what I want to do: Check data and if it looks like a robot, request human verification.
Also this needs to be done on Java (preferably), Perl or PHP.
Thanks
On StackOverflow, it's done by performing the same task too many times too quickly or performing multiple tasks too quickly.
If you want to emulate this, you can keep track of the number and time(s) of recent requests and check to see that everything is within your limits. If it isn't, redirect to a CAPTCHA.
Unfortunately, I don't have enough Java EE experience to provide any code, but hopefully my approach will give you some idea(s).
The simple method would be to log activity (clicks, comments, ect.) and then check the frequency and similarity between these. You can usually detect robots by looking for similar tasks performed repeatedly.
If you are really serious about robot detection, log every keystroke and mouse movements. Regular users have a percentage of error and uncertainty associated with typing and navigating the site. A 100% typo free user that navigates the site easily and quickly (moving the mouse on a straight line from point a to point b) without ever going for the back button is very likely to be a bot.
Related
First time poster, long time lurker. I've gotten a lot of great advice to problems from this site, but I haven't found anything here for the topic of this question. Normally I would bug our SME at the office but he's indisposed.
So, we use Selenium Web Driver to do automated tests. I'm working on an application with some mapping and demographics features, so my tests are very function vs. form oriented.
My tests are written such that I have classes/methods that are a part of the puzzle (the site is essentially one workflow where you go from page 1 to page 5 and the same actions need to be performed in steps 2-3, for example, but test A might do something different on page 4 to see the result in page 5. Clear as mud?
Anyways, during manual tests, I can sometimes see an error message pop up on the site (a hidden div that will become visible if it detects an error, but it's usually a very generic/vague error). This error sometimes pops up even if you're able to go through the flow with no other ill-effects. However, I want to capture when these errors happen so I can look for patterns - if this means just logging it to console or failing the test...I can figure that out later.
The immediate problem is having a persistent check in place that will always look for this error during every test. I could create a method and call it in my "action" methods, though this would leave gaps and slow the tests down. Is there any clever way of implementing something like this without slowing the tests down or calling this check every time I do a step in the process? Also, forgive me, I'm still learning Java and the selenium web driver, so if I've said anything stupid, that's why.
Since this message is persistent if it is there, you might try adding a check for it in your test case teardown method. (I would recommend that you reduce the implicit wait time before you do that check, though, otherwise each test will take an extra amount of time waiting for an error message that isn't there.)
Another possible option is to define your own listener on your own test runner and update the testFinished() method to go check for your error message. See this for some ideas.
Since it sounds like the error messages are always in known locations on each page, I would create a method (or methods, depending on how many error message locations there are on a given page) that looks to see if an error exists and then log it before leaving the page. It sounds like you might be using the page object model. If so, you can add these methods to the each relevant page object for easy access.
NOTE: Checking for errors once before you leave the page may not be enough. You may need to check each time you do some action that might cause an error. This is probably not a bad practice anyway because it will help in debugging errors because you will notice an error closer to the time it was triggered, thus narrowing down what caused the error.
If you have the ability, do something like log it as a warning so that it doesn't fail your test but stands out (and is searchable) in your logs.
You seem concerned that checking for all these errors will significantly slow your script. If properly written, it shouldn't add a significant delay. One significant delay you might run into is if you have implicit waits turned on and are checking for elements that don't exist (e.g., unless there's an error). This will cause the implicit wait to be applied each time you search for the missing element and will likely add significant time to the run time. My suggestion is to turn off implicit waits and add explicit waits only where needed. Searching for any element will add some time but 25ms here and there should be negligible in an overall script run.
Have you tried using EventFiringWebDriver?
There is an answer here on what it does:
What is EventFiringWebDriver in selenium?
Newer selenium versions have more types of events present in the interface, which can broaden its use on these types of tests.
I'm writing a screen saver type app that needs to stop the user from accessing the system without typing a password. I want to catch/supress the various methods a user might try to exit the application, but all research I do seems to point me to "you can't".
Anything in C# or C++ would be great.
I've thought of disabling the keyboard, but then I would have other issues.
You can't. The whole point of Ctrl+Alt+Del is that only the system gets to handle it, 'cause that way the system can always handle it.
Fortunately, Windows has built-in support for password-protected screensavers (available as the "On resume, password protect" option in Display Properties, or via group policy). Just use that.
To add to what Shog9 said, if your application could intercept ctrl+alt+del, then your application would be able to pretend to be the Windows Login dialog, and by doing so trick the end-user into typing their credentials into your application.
If you do want to replace the Windows Login dialog, see Winlogon and GINA (but this says, "GINA DLLs are ignored in Windows Vista", and I haven't heard what's what for Vista).
if someone asked I'd not tell them they can't.
More specifically, your "application software" can't: instead, by design, only "system software" can do this; and it isn't that you're not allowed to or not able to write system software, but your OP seemed to be quite clearly asking how to do it without writing system software ... and the answer to that is that you can't: because the system is designed to prevent an application from hooking these key combinations.
Can you give me direction to writing the system things.. I actually think this would be better if it were system level.. It's for an OEM so kind of the point really. Also if I wrote it system level, I could write an app to control it.
A keyboard filter device driver, or a GINA DLL, for example, would be considered system software: installed by an administrator (or OEM) and run as part of the O/S.
I don't know about GINA beyond its name; and I've already (above) given a link it in MSDN. I expect that it's Win32 user-mode code.
Device drivers are a different topic: e.g. Getting Started on Driver Development.
Is there a way to remap the keyboard so that delete isn't where it was?
I still not sure that you and/or your boss have the right idea. IMHO you shouldn't be an application which prevents the user from pressing Ctrl-Alt-Del. If you want to stop the user from accessing the system without typing a password, then you ought to lock (password-protect) the system, as if the user had pressed Ctrl Alt Del and then selected "Lock this computer". To unlock the computer they would then need to press Ctrl Alt Del and enter their credentials into WinLogon.
However, ignoring what you ought to do and concentrating instead on what you're capable of doing, if you want to intercept the keyboard, apparently it can be done. I haven't studied keyboards myself, but this post and this post claim success, by writing a "Keyboard Filter Driver" (which is a kind of kernel-mode, not Win32, device driver). If you write one of these though you may get some push-back, e.g. like this reaction from a DDK MVP, or this reaction from an anti-snooping product.
I have not tested it but what about using SetWindowsHookEx()
From MSDN documentantion:
WH_KEYBOARD_LL
Windows NT/2000/XP:
Installs a hook procedure that monitors low-level keyboard input events. For more information, see the LowLevelKeyboardProc hook procedure.
It is possible to intercept crtl+alt+del, though obviously Microsoft made it very difficult to do, because then you could pop-up a fake lock dialog, and record people's passwords.
The answer is to write a device driver. I can't remember if you can just use a plain old keyboard filter, or if you have to write a keyboard ISR. Either way, its certainly possible, but with great pain if you have no driver experience.
As this seems to be a good collection spot for the accrual of various means with which to "intercept" the three key psuedo-break
control alt delete, here is something I encountered yesterday that may be of use.
http://cuinl.tripod.com/Tips/enablectrldel.htm
In my opinion, when it seems that the only practical and timely option is to cut the power (i.e. MECHANICAL removal of the battery of an overloaded android-like handheld computer) to halt whatever procession or malfunction results in rather solid and complete ( or long enduring) irresponsiveness-- it appears that a dangerous and frustrating lineage continues--- and continues to get worse.
Especially with the removal of sensible and straightforward things like mechanical speaker volume controls. ( sure, bulky, more material, but of course that is just the thing, what good to an individual or being is infinite and perfect consciousness without a handle on it or it's experience?)
It is a lineage of approaches to designing the -environment that is responsible for the responsiveness to the user- part of a critical and truly meaningful technological interface. ( The only?)
I say put some buttons --direct-to-hardware-control-- back on the things --at least until the software aspects of these technologies become fully adapted to artificial soft interfacing, which I account for in an exhaustive accounting of all heuristical provisionings.
Even in the mechanics of the universe I bet there's a handy reset, restore, suspend, halt type of function(s) for the safety and fundamental viability of the presence of what would constitute as the designer of all that follows the initiating perpetual mystery of existence: INTELLIGENT AWARENESS and WILL.
"Process Explorer" by Mark Russinovich (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) does it, and it had been doing before Sysinternals was bought by Microsoft.
This article from 2002 updated in 2006 explains one way to do it without writing a keyboard driver.
http://www.codeproject.com/KB/system/preventclose.aspx?msg=1666328
starting taskmgr.exe in hidden window would do the job if you just wanted to suppres the call to task manager
ProcessStartInfo taskmgr = new ProcessStartInfo()
{
FileName = "taskmgr.exe",
WindowStyle = ProcessWindowStyle.Hidden
};
Process.Start(taskmgr);
You could achieve that in XP and before, but with Vista not anymore.
Try investigating if you could write an application that starts itself as a password protected screensaver.
Screensavers can do more than just display pretty pictures - I've seen interactive screensavers before that used the mouse and keyboard to provide a simple game, though I can't remember which version of windows I saw this running on... It could well have been windows 95. (In which case all bets are off).
What about intercepting ctrl and alt keypresses while your program is running, and .cancel'ing those keypresses?
I don't know how well this would work, if at all in Vista, but it's worth a try.
I remember doing something like this around the year 2001, so it was probably running on 98. Been too long since I've even tried to mess with anything like locking out ctrl-alt-del.
Ok.. I'm not going to post the code here
But the gyst is this
create a keyboard hook.
when the user presses ctrl || alt || delete set bools to true.. if they press anything else set them all to false.
switch (p_key)
{
default: Clear(); break;
case Keys.LMenu: altHit = true; break;
case Keys.RMenu: altHit = true; break;
case Keys.LControlKey: ctrlHit = true; break;
case Keys.RControlKey: ctrlHit = true; break;
case Keys.Delete: delHit = true; break;
when the screen has focus looses it to the task manager, close the bloody thing.
The screen flashes so fast the user never notices it.
And I can do what ever I want.
I'll admit this is a kludge, but it does result in the desired effect. (OH I wish I didn't have to do this)
I was reading this doc page, and some thought and searching brought me to this question.
https://learn.microsoft.com/en-us/windows/win32/learnwin32/keyboard-input
I have not tested it, but there is this excerpt:
As the name implies, system key strokes are primarily intended for use
by the operating system. If you intercept the WM_SYSKEYDOWN message,
call DefWindowProc afterward. Otherwise, you will block the operating
system from handling the command.
Seems like a security hole to me if it actually works like it says.
You can still intercept Ctrl + Alt + Del in windows 7.
This is the way Process explorer does it:
http://mygreenpaste.blogspot.com/2005/07/image-file-execution-options-good-evil.html
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is there any way to disable browser back button using Java code? Javascript is not reliable in all browsers.
Your both assumptions are wrong.
1) No one can disable browser back button (of course excluding the vendors :)).
2) Java plays on server side. Javascript plays on client side.
You might want browser onunload function to prompt user.
#Derek did a demo for what I mean : http://jsfiddle.net/DerekL/LZCj7/show/
Simple answer: Yes (for certain definitions of disable).
You are completely free to exercise whatever forms of navigation control on your website, and create a series of once-only urls, which must be accessed in a specific order, thus rendering the back button useless. (you could even cause re-visiting these urls to return to a pre-defined homepage)
Common misconceptions:
You can use javascript to control a browser on a client. - You can't, there's no two ways about it, the javascript is out of your control and can be modified by a 7year-old (this is a conservative estimate based on experience, not expectation.),
Preventing backwards navigation is always hacky and/or bad. Certain things should really attempt to do this better - Ever done an online quiz, or memory game?
Solution:
please note this will not disable the button, and will instead invalidate requests made to a 'previous' url
Include a key in every request (which changes for every subsequent request), and is associated with the HttpSession, this could then be included in form submission - bear in mind, someone who knows what they're doing can still extract this and use it to travel backwards, so it is also worthwhile ensuring that your key can only be used for a specific subset of pages from your entire site (those allowed). Many easy ways to do this, personally I am a fan of primes and hashes.
also note, refreshing a page with this could cause you grief if you have not considered your desired behaviour. Do so, and implement it.
You shouldn't try to disable the back button, as your website shouldn't extend beyond the limits of the viewport, but you should rather try to change your approach. I'm pretty sure that what you want to acheive can be done in another way! Why don't you tell us more about it?
JavaScript was designed to act on DOM elements, and unfortunately, the back button isn't part of them. Also, unlike what you think, JavaScript is reliable, and although the result may slightly vary from one browser to another, there are some libraries that are able to tackle this problem.
As for Java, you might be thinking of applets... But it's still not the right way to go, and in terms of cross-browser compatibility, the situation is much worse than it is with JavaScript.
So, in a nutshell, YES, there might be some workarounds to prevent the use of the back button, but NO, you should'nt try to do it, because it's considered a bad practice.
EDIT:
Here is a snippet of JavaScript (not Java) ode that can prevent the previous page from loading:
<script>
function preventBackButton(){window.history.forward();}
setTimeout("preventBackButton()", 0);
window.onunload=function(){null};
</script>
But remember, this is NOT a good practice. You should NOT use it. Why don't you tell us what you want to achieve so we can help you do it the right way?
It's a very specific problem I have:
I'm working on a text-based RPG, where the main work is to implement an editor, that gives the possibility to add NPCs, Items and place them on the map (...) without any knowledge about programming.
All of these things work fine with doing some SQL queries and the whole thing already works. Now I'm working on quest editing. My basic concept is, that every time the player enters a command, a database entry for the specific string is queried, that's linked to a set of conditions and actions, which have unique IDs. Those are queried in the java code, where a specific condition (e.g. that the players money equals 100) has a part of code that returns the result. This means, that hundreds (or more) IFs have to be passed, each time a command is entered - same with the actions according to the command. I'm not even sure if that is the right way (If anyone has a propose to this, feel free to post).
The point is now, that quests basically consist of quest stages, which also have conditions to be enabled and actions, performed when enabled. That means, that also with each entered command, all of these queries have to take place. I thought about using some kind of trigger, but I don't have a good idea how to implement it, because I don't really want to edit java code out of this editor. I also considered using prolog, but also in that case I'd have to add triggers into java code I guess.
I know that this is a little bit hard to handle in a forum like this, but if anyone has a suggestion, I'd be really glad.
EDIT:
As suggested in a comment, I'd like to shorten the whole thing: If any command (out of houndres or thousands) could trigger one particular quest/quest stage (out of thousands) and these triggers should be set with an editor, what's a proper way to implement that?
reasoning over lots of facts and triggering actions when a set of facts matches specific conditions is a good match for drools.
you could represent every action/decision that the player has made as a fact, which you could insert into a drools knowledge session.
in that session you could store all of your "triggers" as drools rules, which will fire when a collection of facts in memory match the condition.
drools supports dynamic addition/removal/editing of rules and is explicitely targeted at allowing non-developers to write logic using a simpler rule language.
the specific part of drools to start with is the core - drools expert
I have a software design question on what's the best way to handle a client javascript program that relies in multiple (but mostly consecutive, not simultaneous), short-lived AJAX calls to the server as a response to user interaction [in my particular case, it will be a facebook-GAE/J app, but I believe the question is relevant to any client(browser)/server design].
First, I asked this question: What is the life span of an ajax call? . Based on BalusC answer (I encourage it to read it there), the short answer is "that's up to the browser". So, right now I do not have really control of what's happening after the server sent the response.
If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?
Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?
Is it possible to manually set the limit per domain?
And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.
Thank you in advance
The usage paradigm for XHR is that you don't have to worry about what happens to the object -- the browser's engine takes care of that behind the scenes for you. So I don't see any point in attempting to "improve" things manually. Browser developers are certainly aware that 99.9999% of JS programmers do not do that, so they have not only taken it into account but probably optimized for that scenario as well.
You should not worry about it unless and until you have a concrete problem in your hands.
As for limiting the number of AJAX calls per domain (either concurrent outstanding calls, or total calls made, or any other metric you might be interested in), the solution would be the venerable CS classic: add another layer of abstraction.
In this case, the extra layer of abstraction would be a function through which all AJAX calls would be routed through; you can then implement logic that tracks the progress of each call (per domain if you want it to) and rejects or postpones incoming calls based on that state. It won't be easy to get it correctly, but it's certainly doable.
However, I suggest also not worrying about this unless and until you have a concrete problem in your hands. :)
Update:
Browsers do enforce their own limits on concurrent AJAX calls; there's a very good question about that here: How many concurrent AJAX (XmlHttpRequest) requests are allowed in popular browsers?
Also, as T. J. Crowder mentions in the comments: make sure you are not keeping references to XHR objects when you are done with them, so that they can be garbage collected -- otherwise, you are creating a resource leak yourself.
Second update:
There is a good blog post about reusing XHR here -- it's actually the start of a chain of relevant posts. On the down side, it's dated and it doesn't come to any practical conclusion. But it covers the mechanics of reusing XHR well.
If the main use for an AJAX call is to retrieve data just once from the server, is it possible to manually destroy it? Would xhr1.abort() do that?
It only aborts the running request. It does not close the connection.
Or, the best choice is leave it like that? Would manually closing each connection (if even possible) add too much overhead to each call?
Not possible. It's the browser's responsibility.
Is it possible to manually set the limit per domain?
Not possible from the server side on. This is a browser specific setting. Best what you could to is to ask in some page dialog the enduser to change the setting if not done yet. But this makes after all no sense, certainly not if the enduser does totally not understand the rationale behind this.
And last (but not least!), should I really worry about this? What would be a number of calls large enough to start delaying the browser (specially some IE browsers with the leak bug that BalusC mentioned in the other question? Please, bear in mind that this is my first javascript/java servlets project.
Yes, you should certainly worry about browser specific bugs. You want your application to work without issues, do you? Why wouldn't you just use an existing ajax library like jQuery? It has already handled all nasty bugs and details under the covers for you (which is many more than only MSIE memory leaking). Just call $.ajax(), $.get(), $.post() or $.getJSON() and that's it. I wouldn't attempt to reinvent the XHR handling wheel when you're fairly new to the materials. You can find some jQuery-Servlet communication examples in this answer.