I'm trying to reduce the form spam on our website. (It's actually pretty recent).
I seem to remember reading somewhere that the spammers aren't executing the Javascript on the site.
Is that true?
And if so, then could you simply check for javascript being disabled and then figure it's likely that it's spam?
There are still a large number of people that run with Javascript turned off.
Alternatively, I have had decent success with stopping form spam using CSS. Basically, include an input field and label that is hidden using CSS (display: none;) and once submitted, check if anything has been entered in the field.
I generally label the field as a spam filter with an instruction to not put anything in the field, but all newer browsers will properly hide the block.
More: Fighting Spam with CSS
reCAPTCHA is also surprisingly easy to implement.
check http://kahi.cz/wordpress/ravens-antispam-plugin/ for a nice answer
if puts in
<noscript><p><label for="websiteurl99f">Please type "e73053": </label><input type="text" name="websiteurl99f" id="websiteurl99f" /></p></noscript>
<script type="text/javascript">/* <![CDATA[ */ document.write('<div><input type="hidden" name="websiteurl99f" value="e' + '73053" \/><\/div>'); /* ]]> */</script>
so javascript users see nothing, non js users just type in a word
if a spammer targets you specifically it won't take them long to code round it but for drive by spammers it should be good
In the same vein, adding a dummy field and then using CSS to hide it is a good way to trick the bots. If the field is submitted, you know a non-human probably completed the form.
Especially effective if you label/name the field something along the lines of URL or website.
You could check - have JavaScript that populates a hidden form field with a specific value after the page loads. Then, when the page posts back to the server, check that hidden form field the expected value. If it is not there, that means the JavaScript didn't execute.
As to whether you should assume it is spam is another story altogether, and one that has no certain answer, really. You could simply have a <noscript> tag and have it indicate to the user that their submission will not take unless they enable JavaScript.
Once you have JavaScript running, however, the spammers will just use another workaround for that. :)
I can't remember where I've seen this method but spam bots like to fill out forms. Have you considered putting a form field that is hidden with javascript (and says don't fill this field if the user doesn't have JavaScript). This way if something fills in this field you can ignore it as spam.
Did you have any luck with this? I think some text based browsers have implemented basic JavaScript support, so maybe spam bots have as well?
Otherwise I'm considering using a captcha for users without JavaScript and some automatic JavaScript check for other users.
Related
As you may know, Chrome does not support:autocomplete="off", autocomplete="nope", autocomplete="false" or even autocomplete="new-password" any longer.
That means, from time to time, I do get reports that honeypot traps are preventing users from submitting forms, since the trap input is being auto-filled, even if not shown.
The practice for setting the trap is wrapping a TEXT input with a display:none; element, so spam bots won't be able to figure its really hidden (unless they are smarter and they usually aren't), and if this input has contents, you won't allow the submission to go through, as the field supposed to be hidden and empty for regular users.
What's your practice in using honeypot traps while still having browsers ignoring the demand for auto-complete or auto-fill by using the above arributes?
My current solution (October 2022) for a honeypot field looks like this:
Move the input field out of the visible area using css
Avoid name attributes that Chrome looks for when autofilling, like email, address, etc.
Do not wrap the honeypot input element with other elements that contain such keywords in their label or in name attribute
If you are using FormFind (which analyzes a page's source code and extracts the 'action' parameter and the input tags will find hidden fields. Hidden fields will not stop a spambot.
FormFind will find all the fields on a form from the HTML source code. And once you find the input fields - and the 'action' parameter (which FormFind does find) - its easy to use CURL or WGET to 'submit' the form.
Although reCAPTCHA will help with spambots, the only technique that I have found (and what I use in my solution) is to have some JavaScript code that will change the form's action parameter on a onclick/onfocus event. And if you put a delay in the JS function that changes the action parameter, that's a bonus spambot blocker.
Using JS to change things (or even to fill in a hidden field, if you insist on using one) is a good technique. CUSL and WGET cannot process JS code. (There was an open source project that claimed to be able to process JS code, but it was abandoned a couple of years ago.)
The JS trick is what I use in my contact form at my free FormSpammerTrap.com site. Code is free and open source. And the contact form there uses my technique. Have not gotten any spam via a spambot (automated process) from there. And I am working on a newer version that will add delays to even further block spammers.
Anyone is welcome to request the code to try it out. No charge. No fees. No advertising. No $$ benefit to me, other than how I use it on my sites to block spam.
So, using hidden fields to stop spambots is not going to work well. You have to have more layers of defense against them. Using JS code techniques is another layer that will help block almost all spambots. (There's no 100% solution, but I think mine is close - and it's been around for a couple of years.)
I removed the name variable from the input tag and this resolved the issue of the hidden honey pot fields getting autofilled...
So basically, the website is javascript free. No javascript at all. Will not be adding javascript.
However, we need to prompt the end user to enter information accordingly to be used in a database that will then connect to software on the network.
As in, there are 2 hyphens preinserted into a form field for a telephone number. This will prompt the user to enter 310-555-5555 instead of 3105555555.
*** I am a translator for a website owner and a web developer. I am not a programmer. I need a simple answer. I dont need you to explain how to do it. I just need to find out if the programmer is capable or if the website owner is asking for something impossible.
Yeah, it is absolutely possible. There are HTML placeholder attributes available which will do your job.
For modern browsers the HTML attribute placeholder already exists and does exactly what you mentioned.
http://caniuse.com/#feat=input-placeholder Browser support is pretty strong nowadays
Side notes that may not be needed after you further clarified you wouldn't be doing the work:
With that said it gets a little bit more involved if you want to have all users get that information and see it (this is in regards to accessibility). Also placeholders disappear after a user starts typing. Not sure if that is an issue.
Having the explanation part of the label as well (styled differently) will make it always visible and readable by different user interaction.
You can use placeholder attribute to prompt the user to insert a specific format and pattern attribute to validate the pattern entered.
<form>
<input type="text" pattern="\d{3}[- ]?\d{3}[- ]?\d{4}" placeholder="XXX-XXX-XXXX">
<input type="submit">
</form>
I'm working on an input form, and I have a Javascript function that gets all of the field values when you press a button. I am looking for a way to automatically refresh the Javascript values (so I can, for example, check if a username is too short on a registration page as they type, and also check if the username is available). Would this be possible?
To clarify, I have an HTML input field (for text), and as the user is typing a result, automatically update.
I'm also open to using PHP or jQuery if it's not possible using solely Javascript, but I'd prefer Javascript if it's possible. Also, sorry if this is a rather basic question, but I've searched and searched and can't find anything on it. I know it's possible because I've seen it on websites (in fact, even on this one, as you type a question, it updates the preview at the bottom).
You should use JQuery Validation Plugin to reduce the heavy checking.
Check this one out at http://jquery.bassistance.de/validate/demo/
No jQuery needed
<input type="text" onKeyUp="validate(this.value);">
function validate(value){
//validate code on value
}
You should monitor onkeyup event
<input type="text" id="test">
$('#test').on('keyup', function() { //this function is triggered every time the user releases a key while typing inside the text field above
//do whatever you want here
});
Input fields are usually associated to forms, but I would like to use them in a simple Javascript/HTML page. I don't need the form. I see no issue with my HTML page, but is there any danger or bad practice I am not aware of? I just don't want my page to bug down the road.
(Basically, a field in my page can be Javascript enabled or disabled according to values in other fields)
The only real problem is if you want your page to function for users who have JavaScript disabled - if the inputs are actually for user input then placing them outside a form means that you'd need to use JavaScript (presumably with Ajax) to do anything with the values, whereas form fields can be submitted without JavaScript. If your page isn't intended to be submitted to the server anyway then you're dependent on JavaScript for interaction. If you've taken that into account and it doesn't matter for your scenario then go ahead.
P.S. I should've mentioned that as far as HTML standards go it is perfectly valid to have input elements that aren't in forms.
You should be fine AFAIK. It's ok in the HTML 4.01 standards anyway
http://www.w3.org/TR/html401/interact/forms.html#form-controls
The elements used to create controls generally appear inside a FORM
element, but may also appear outside of a FORM element declaration
when they are used to build user interfaces. This is discussed in the
section on intrinsic events. Note that controls outside a form cannot
be successful controls.
You can use an HTML validator (here, or on many other sites) to check this sort of thing. If it shows up legal, which I think it should in this case, as Ted pointed out, then you are probably good.
When a user creates an account on certain sites, it sometimes require the user's basic information such as name, email, and location. Chrome has the ability to autofill this form if the user had previously entered his/her information.
My question is: is it possible to detect/identify whether the page the user is visiting can be autofilled?
A naive solution would be to parse every page for forms that can be autofilled. But is there a more elegant solution?
What do you want exactly? Every form CAN be autofilled, obviously, so the answer is YES to the question in your text.
The question in your headline is a much different one - HAS the form been auto-filled?
There is a pretty good approximation: if you check on load if there are any values in the form (that differ from the ones you sent), and there are, the user can't have filled them manually, obviously. So then you know that auto-fill has taken place.
On the other hand, it almost sounds as if you are looking for a generic solution not for your own site but for a browser extension you yourself want to write? In that case the solution is the same though, immediately on page load look at the values the page provides and see if the ones actually there differ. I'm not exactly sure, but the onload event should be fine, I think autofill doesn't happen before the page has loaded. Maybe you'll even need to add a few hundred milliseconds on top of the onload event. The user can't type much anyway in less than a second, or select checkboxes etc., so it's still a very good guess.
Anyway, even after re-reading your headline and your question I'm actually MORE confused about what exactly you want to achieve - but as Douglas Adams wasn't the first one to try to teach us, often it's not the answer but the question itself that is the problem :)
well, you can check for the default value value="VALUE" has changed
i.e:
if (getElementById('inputID').value != 'VALUE') { // DO SOMETHING }
or
check if value has changed:
input type="text" onchange="alert('changed')">
one of these two should help you ( i hope :) )
You could use
document.querySelectorAll('*:-webkit-autofill');
to get all elements autofilled.
Then you just have to check if any new elements is in there in a loop.