I'm trying to come up with a good enough anti-spamming mechanism to prevent automatically generated input. I've read that techniques like captcha, 1+1=? stuff work well, but they also present an extra step impeding the free quick use of the application (I'm not looking for anything like that please).
I've tried setting some hidden fields in all of my forms, with display: none;
However, I'm certain a script can be configured to trace that form field id and simply not fill it.
Do you implement/know of a good anti automatic-form-filling-robots method? Is there something that can be done seamlessly with HTML AND/OR server side processing, and be (almost) bulletproof? (without JS as one could simply disable it).
I'm trying not to rely on sessions for this (i.e. counting how many times a button is clicked to prevent overloads).
I actually find that a simple Honey Pot field works well. Most bots fill in every form field they see, hoping to get around required field validators.
http://haacked.com/archive/2007/09/11/honeypot-captcha.aspx
If you create a text box, hide it in javascript, then verify that the value is blank on the server, this weeds out 99% of robots out there, and doesn't cause 99% of your users any frustration at all. The remaining 1% that have javascript disabled will still see the text box, but you can add a message like "Leave this field blank" for those such cases (if you care about them at all).
(Also, noting that if you do style="display:none" on the field, then it's way too easy for a robot to just see that and discard the field, which is why I prefer the javascript approach).
An easy-to-implement but not fool-proof (especially on "specific" attacks) way of solving anti-spam is tracking the time between form-submit and page-load.
Bots request a page, parse the page and submit the form. This is fast.
Humans type in a URL, load the page, wait before the page is fully loaded, scroll down, read content, decide wether to comment/fill in the form, require time to fill in the form, and submit.
The difference in time can be subtle; and how to track this time without cookies requires some way of server-side database. This may be an impact in performance.
Also you need to tweak the threshold-time.
What if - the Bot does not find any form at all?
3 examples:
Insert your form using AJAX
If you are OK with users having JS disabled and not being able to see/ submit a form, you can notify them and have them enable Javascript first using a noscript statement:
<noscript>
<p class="error">
ERROR: The form could not be loaded. Please enable JavaScript in your browser to fully enjoy our services.
</p>
</noscript>
Create a form.html and place your form inside a <div id="formContainer"> element.
Inside the page where you need to call that form use an empty <div id="dynamicForm"></div> and this jQuery: $("#dynamicForm").load("form.html #formContainer");
Build your form entirely using JS
// THE FORM
var $form = $("<form/>", {
appendTo : $("#formContainer"),
class : "myForm",
submit : AJAXSubmitForm
});
// EMAIL INPUT
$("<input/>",{
name : "Email", // Needed for serialization
placeholder : "Your Email",
appendTo : $form,
on : { // Yes, the jQuery's on() Method
input : function() {
console.log( this.value );
}
}
});
// MESSAGE TEXTAREA
$("<textarea/>",{
name : "Message", // Needed for serialization
placeholder : "Your message",
appendTo : $form
});
// SUBMIT BUTTON
$("<input/>",{
type : "submit",
value : "Send",
name : "submit",
appendTo : $form
});
function AJAXSubmitForm(event) {
event.preventDefault(); // Prevent Default Form Submission
// do AJAX instead:
var serializedData = $(this).serialize();
alert( serializedData );
$.ajax({
url: '/mail.php',
type: "POST",
data: serializedData,
success: function (data) {
// log the data sent back from PHP
console.log( data );
}
});
}
.myForm input,
.myForm textarea{
font: 14px/1 sans-serif;
box-sizing: border-box;
display:block;
width:100%;
padding: 8px;
margin-bottom:12px;
}
.myForm textarea{
resize: vertical;
min-height: 120px;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<div id="formContainer"></div>
Bot-bait input
Bots like (really like) saucy input elements like:
<input
type="text"
name="email"
id="email"
placeholder="Your email"
autocomplete="nope"
tabindex="-1"
They wll be happy to enter some value such as
`dsaZusil#kddGDHsj.com`
After using the above HTML you can also use CSS to not display the input:
input[name=email]{ /* bait input */
/* do not use display:none or visibility:hidden
that will not fool the bot*/
position:absolute;
left:-2000px;
}
Now that your input is not visible to the user expect in PHP that your $_POST["email"] should be empty (without any value)! Otherwise don't submit the form.
Finally,all you need to do is create another input like
<input name="sender" type="text" placeholder="Your email"> after (!) the "bot-bait" input for the actual user Email address.
Acknowledgments:
Developer.Mozilla - Turning off form autocompletition
StackOverflow - Ignore Tabindex
What I did is to use a hidden field and put the timestamp on it and then compared it to the timestamp on the Server using PHP.
If it was faster than 15 seconds (depends on how big or small is your forms) that was a bot.
Hope this help
A very effective way to virtually eliminate spam is to have a text field that has text in it such as "Remove this text in order to submit the form!" and that text must be removed in order to submit the form.
Upon form validation, if the text field contains the original text, or any random text for that matter, do not submit the form. Bots can read form names and automatically fill in Name and Email fields but do not know if they have to actually remove text from a certain field in order to submit.
I implemented this method on our corporate website and it totally eliminated the spam we were getting on a daily basis. It really works!
How about creating a text field input box the same color as the background which must remain blank. This will get around the problem of a bot reading display:none
http://recaptcha.net/
reCAPTCHA is a free antibot service that helps digitize books
It has been aquired by Google (in 2009):
https://www.google.com/recaptcha
https://developers.google.com/recaptcha/
Also see
https://en.wikipedia.org/wiki/ReCAPTCHA
https://en.wikipedia.org/wiki/CAPTCHA for more general information
Many of those spam-bots are just server-side scripts that prowl the web. You can combat many of them by using some javascript to manipulate the form request before its sent (ie, setting an additional field based on some client variable). This isn't a full solution, and can lead to many problems (eg, users w/o javascript, on mobile devices, etc), but it can be part of your attack plan.
Here is a trivial example...
<script>
function checkForm()
{
// When a user submits the form, the secretField's value is changed
$('input[name=secretField]').val('goodValueEqualsGoodClient');
return true;
}
</script>
<form id="cheese" onsubmit="checkForm">
<input type="text" name="burger">
<!-- Check that this value isn't the default value in your php script -->
<input type="hidden" name="secretField" value="badValueEqualsBadClient">
<input type="submit">
</form>
Somewhere in your php script...
<?php
if ($_REQUEST['secretField'] != 'goodValueEqualsGoodClient')
{
die('you are a bad client, go away pls.');
}
?>
Also, captchas are great, and really the best defense against spam.
I'm surprised no one had mentioned this method yet:
On your page, include a small, hidden image.
Place a cookie when serving this image.
When processing the form submission, check for the cookie.
Pros:
convenient for user and developer
seems to be reliable
no JavaScript
Cons:
adds one HTTP request
requires cookies to be enabled on the client
For instance, this method is used by the WordPress plugin Cookies for Comments.
With the emergence of headless browsers (like phantomjs) which can emulate anything, you can't suppose that :
spam bots do not use javascript,
you can track mouse events to detect bot,
they won't see that a field is visually hidden,
they won't wait a given time before submitting.
If that used to be true, it is no longer true.
If you wan't an user friendly solution, just give them a beautiful "i am a spammer" submit button:
<input type="submit" name="ignore" value="I am a spammer!" />
<input type="image" name="accept" value="submit.png" alt="I am not a spammer" />
Of course you can play with two image input[type=image] buttons, changing the order after each load, the text alternatives, the content of the images (and their size) or the name of the buttons; which will require some server work.
<input type="image" name="random125454548" value="random125454548.png"
alt="I perfectly understand that clicking on this link will send the
e-mail to the expected person" />
<input type="image" name="random125452548" value="random125452548.png"
alt="I really want to cancel the submission of this form" />
For accessibility reasons, you have to put a correct textual alternative, but I think that a long sentence is better for screenreaders users than being considered as a bot.
Additional note: those examples illustrate that understanding english (or any language), and having to make a simple choice, is harder for a spambot than : waiting 10 seconds, handling CSS or javascript, knowing that a field is hidden, emulating mouse move or emulating keyboard typing, ...
A very simple way is to provide some fields like <textarea style="display:none;" name="input"></textarea> and discard all replies that have this filled in.
Another approach is to generate the whole form (or just the field names) using Javascript; few bots can run it.
Anyway, you won't do much against live "bots" from Taiwan or India, that are paid $0.03 per one posted link, and make their living that way.
I have a simple approach to stopping spammers which is 100% effective, at least in my experience, and avoids the use of reCAPTCHA and similar approaches. I went from close to 100 spams per day on one of my sites' html forms to zero for the last 5 years once I implemented this approach.
It works by taking advantage of the e-mail ALIAS capabilities of most html form handling scripts (I use FormMail.pl), along with a graphic submission "code", which is easily created in the most simple of graphics programs. One such graphic includes the code M19P17nH and the prompt "Please enter the code at left".
This particular example uses a random sequence of letters and numbers, but I tend to use non-English versions of words familiar to my visitors (e.g. "pnofrtay"). Note that the prompt for the form field is built into the graphic, rather than appearing on the form. Thus, to a robot, that form field presents no clue as to its purpose.
The only real trick here is to make sure that your form html assigns this code to the "recipient" variable. Then, in your mail program, make sure that each such code you use is set as an e-mail alias, which points to whatever e-mail addresses you want to use. Since there is no prompt of any kind on the form for a robot to read and no e-mail addresses, it has no idea what to put in the blank form field. If it puts nothing in the form field or anything except acceptable codes, the form submission fails with a "bad recipient" error. You can use a different graphic on different forms, although it isn't really necessary in my experience.
Of course, a human being can solve this problem in a flash, without all the problems associated with reCAPTCHA and similar, more elegant, schemes. If a human spammer does respond to the recipient failure and programs the image code into the robot, you can change it easily, once you realize that the robot has been hard-coded to respond. In five years of using this approach, I've never had a spam from any of the forms on which I use it nor have I ever had a complaint from any human user of the forms. I'm certain that this could be beaten with OCR capability in the robot, but I've never had it happen on any of my sites which use html forms. I have also used "spam traps" (hidden "come hither" html code which points to my anti-spam policies) to good effect, but they were only about 90% effective.
Another option instead of doing random letters and numbers like many websites do, is to do random pictures of recognizable objects. Then ask the user to type in either what color something in the picture is, or what the object itself is.
All in all, every solution is going to have its advantages and disadvantages. You are going to have to find a happy median between too hard for users to pass the antispam mechanism and the number of spam bots that can get through.
the easy way i found to do this is to put a field with a value and ask the user to remove the text in this field. since bots only fill them up. if the field is not empty it means that the user is not human and it wont be posted. its the same purpose of a captcha code.
I'm thinking of many things here:
using JS (although you don't want it) to track mouse move, key press, mouse click
getting the referral url (which in this case should be one from the same domain) ... the normal user must navigate through the website before reaching the contact form: PHP: How to get referrer URL?
using a $_SESSION variable to acquire the IP and check the form submit against that list of IPs
Fill in one text field with some dummy text that you can check on server side if it had been overwritten
Check the browser version: http://chrisschuld.com/projects/browser-php-detecting-a-users-browser-from-php.html ... It's clear that a bot won't use a browser but just a script.
Use AJAX to send the fields one by one and check the difference in time between submissions
Use a fake page before/after the form, just to send another input
I've added a time check to my forms. The forms will not be submitted if filled in less than 3 seconds and this was working great for me especially for the long forms. Here's the form check function that I call on the submit button
function formCheck(){
var timeStart;
var timediff;
$("input").bind('click keyup', function () {
timeStart = new Date().getTime();
});
timediff= Math.round((new Date().getTime() - timeStart)/1000);
if(timediff < 3) {
//throw a warning or don't submit the form
}
else submit(); // some submit function
}
Decided to add another answer, sorry.
We use a combination of two:
Honeypot field with name="email" (already mentioned by other answers) just be sure to use a sophisticated way to hide it , like moving off the screen or something. Because bots can detect display:none
A hidden field that is set by JavaScript when the user clicks (or focuses if you want to be TAB-friendly) on a required field (wasn't mentioned in other answers)
The 2nd option can even protect from a headless-browser type of spam (using phatnom.js or Selenium) because even JavaScript-bots don't bother actually clicking textboxes.
Blocks 99% of bots.
PS. Make sure to use the focus trick only on fields that are not being filled by password managers like LastPass or 1Passwor.
For the same reasons - mark your honeypot with autocomplete="false" tabindex="-1"
The best solution I've found to avoid getting spammed by bots is using a very trivial question or field on your form.
Try adding a field like these :
Copy "hello" in the box aside
1+1 = ?
Copy the website name in the box
These tricks require the user to understant what must be input on the form, thus making it much harder to be the target of massive bot form-filling.
EDIT
The backside of this method, as you stated in your question, is the extra step for the user to validate its form.
But, in my opinion, it is far simpler than a captcha and the overhead when filling the form is not more than 5 seconds, which seems acceptable from the user point of view.
Its just an idea, id used that in my application and works well
you can create a cookie on mouse movement with javascript or jquery and in server side check if cookie exist, because only humans have mouse, cookie can be created only by them
the cookie can be a timestamp or a token that can be validate
In my experience, if the form is just a "contact" form you don't need special measures. Spam get decently filtered by webmail services (you can track webform requests via server-scripts to see what effectively reach your email, of course I assume you have a good webmail service :D)
Btw I'm trying not to rely on sessions for this (like, counting how
many times a button is clicked to prevent overloads).
I don't think that's good, Indeed what I want to achieve is receiving emails from users that do some particular action because those are the users I'm interested in (for example users that looked at "CV" page and used the proper contact form). So if the user do something I want, I start tracking its session and set a cookie (I always set session cookie, but when I don't start a session it is just a fake cookie made to believe the user has a session). If the user do something unwanted I don't bother keeping a session for him so no overload etc.
Also It would be nice for me that advertising services offer some kind of api(maybe that already exists) to see if the user "looked at the ad", it is likely that users looking at ads are real users, but if they are not real well at least you get 1 view anyway so nothing loss. (and trust me, ads controls are more sophisticated than anything you can do alone)
Actually the trap with display: none works like a charm. It helps to move the CSS declaration to a file containing any global style sheets, which would force spam bots to load those as well (a direct style="display:none;" declaration could likely be interpreted by a spam bot, as could a local style declaration within the document itself).
This combined with other countermeasures should make it moot for any spam bots to unload their junk (I have a guest book secured with a variety of measures, and so far they have fallen for my primary traps - however, should any bot bypass those, there are others ready to trigger).
What I'm using is a combination of fake form fields (also described as invalid fields in case a browser is used that doesn't handle CSS in general or display: none in particular), sanity checks (i. e. is the format of the input valid?), time stamping (both too fast and too slow submissions), MySQL (for implementing blacklists based on e-mail and IP addresses as well as flood filters), DNSBLs (e. g. the SBL+XBL from Spamhaus), text analysis (e. g. words that are a strong indication for spam) and verification e-mails (to determine whether or not the e-mail address provided is valid).
One note on verification mails: This step is entirely optional, but when one chooses to implement it, this process must be as easy-to-use as possible (that is, it should boil down to clicking a link contained in the e-mail) and cause the e-mail address in question to be whitelisted for a certain period of time so that subsequent verifications are avoided in case that user wants to make additional posts.
I use a method where there is a hidden textbox. Since bots parse the website they probably fill it. Then I check it if it is empty if it is not website returns back.
Add email verification. The user receives an email and he needs to click a link. Otherwise discard the post in some time.
You can try to cheat spam-robots by adding the correct action atribute after Javascript validation.
If the robot blocks Javascript they can never submit the form correctly.
HTML
<form id="form01" action="false-action.php">
//your inputs
<button>SUBMIT</button>
</form>
JAVASCRIPT
$('#form01 button').click(function(){
//your Validations and if everything is ok:
$('#form01').attr('action', 'correct-action.php').on("load",function(){
document.getElementById('form01').submit()
});
})
I then add a "callback" after .attr() to prevent errors.
Related
I have a web application for tagging data and viewing data by tag, so my UI is a list of checkboxes for each tag, a list of checkboxes for each data item, a "Tag" button, which adds the checked tags to the checked data, and a "Filter" button, which ignores the checked data and just displays only the data items with the given tag.
My problem is that the former operation (tagging data) is "obviously" a POST operation, whereas the latter operation (viewing data according to a tag) is "obviously" a GET operation. But the method attribute is attached to the form, not the submit button, so I have to choose one or other for both buttons.
I don't want to make two forms, since as far as I can tell this would force me to duplicate the entire tag list. Is there any way I can choose my method based on the choice of submit button?
A JavaScript solution is permissible, but one without would be preferred.
(I am going to post an answer to this question, but I don't particularly like it, so I would welcome alternatives).
In principle, you could use the formmethod attribute in a submit button, as per HTML5. However, it is not recognized by IE, even in IE 9. The existence of the feature in HTML5 indirectly proves that previous versions of HTML lack a feature for this.
On the other hand, the POST method can be used even for simple viewing that does not cause any changes in the outside world, and in many situations it has to be used for technical reasons (e.g., too much data). So I think the method issue is not very relevant; just use POST.
I would honestly go with a javascript solution, in the onsubmit of the form fire a method which a) checks the submit button that was pressed and b) based on this changes the method of the form.
One possible solution would be to use POST, and then have the server give a 303 See Other header to change it into a GET request. This involves making two requests to serve the purpose of one, which is unfortunate, but at least means that the URL will change so people can link to a specific tag selection.
I agree with javascript solution, proposed by Jon Taylor, the problem is not if your form's method is GET or POST, but how do you filter/validate/sanitize user input. If your concern is related to the fact, that the user can manipulate the form's method, then you should implement solution to that matter on server side.
Assume I have a html from, and it contain some submit type. I want to create a "are you sure" popup window that will appear when user click submit button.
My question is that is there any way to create it by using "only" html, not using javascript or any other?
HTML only is possible, but not without a postback
Scenario that could work without javascript:
You have your form with submit button
User clicks (and submits) the form
You display another form with are you sure? form (that contains Yes and No buttons as well as hidden fields of the first form that will make it possible to do the action required on the original data
functionality that executes the action and goes back to whatever required.
This would be completely Javascript free, but it would require several postbacks.
This kind of thing is usually done on the client with a Javascript confirm() function (here's a simple example) or lately with a more user friendly modal dialog provided by many different client libraries or their plugins.
When to choose the script free version?
If you know your clients are going to be very basic ones (ie. vast majority of your users will access your application using clients like Opera Mini that's not able to run scripts at all). But in all other cases it's much better to do this using Javascript. It will be faster, easier to develop and much more user friendly. Not to mention that it will put less strain on your server as well since certain parts will execute on the client without the need of any server processing.
No, there isn't. Despite of the new features in HTML 5, HTML is still a markup language, not a programming language. In order to express dynamic behavior (such as an "are you sure?" box), you need to use a programming language.
Javascript would be the most obvious choice for this, but you could also do it with frameworks that can get you around writing Javascript by hand (for example ASP.NET).
Edit: Actually it appears that it would theoretically possible to do this with without Javascript or other frameworks. As I just learned, HTML 5 + CSS 3 seems to be turing complete. But this is hardly relevant to this question.
It's possible to ask for a confirmation, but it will not be in a "popup window". The creation of the "popup window" requires javascript/other language.
It will be:
Request (first form)
POST
Response (confirmation form)
POST
Response (outcome message)
You can create a form with all hidden elements containing the data from the first form and a "Yes" and "No" button below the "Are you sure?" text. You can use PHP sessions to avoid the hidden form elements. If there is a lot of data or confidential data or you do not want to re-validate the data from the second form, use sessions. Make sure you validate the data from either form before using it.
I know I'm like .. 10 years late. But for anyone still wondering I thought I could be of some help!
What I did for this exact problem was make sure I had multiple "divs" in my code. For me specifically, I had two main ones.
First, one whose id="main", and another whose id="popup" with the 'visible' property initially set to 'false' for the popup div.
Then, on whichever event you're looking for (button click for example) you'll simply set main.Visible = false and popup.Visible = true, then you could have more buttons in your popup (yes, no, cancel, confirm, etc.) which do the exact same thing, but in reverse!
The most important thing to make sure of is that you have the 'runat="server"' property in your divs so that you can access them in your CS code
Hope this was helpful! :)
Is there an easy way to check to see if someone has modified your HTML? I am currently writing some code that takes data from the DOM and submits it to the backend where it will of course be sanitized and checked for accuracy, but I was wondering if there was a way to kind of head that off at the pass.
For instance, if I have a hidden input with a number in it and someone modifies that number in Firebug before submitting it to my server, is there a way to check to see if the actual HTML was modified before submitting the request to the server and basically telling them HEY BUDDY STOP MESSING WITH MY STUFF.
I'm not entirely sure this is possible, but if it is, I do not know how to do it.
Hmm, I'd say that the HTML on your users' browser is actually theirs. (i.e. nothing wrong with greasemonkey) Stuff isn't yours again until it arrives at your server in the form of the URL, HTML form input parameters, and cookies -- all of which can of course be modified unbenknownst to you. So you should continue to validate such data; there's no magic bullet to allow for a trusted client experience.
You could send along with your hidden value another value that is the result of a complex computation you performed involving the hidden value and some secret value that never gets sent to the client. Then when you receive the hidden value simply perform another calculation that reverses the first one. If you don't get your secret value back then you know they have changed the hidden value.
Of course, this is still not going to be that secure as someone can easily do some experiments on your site and find out what that secret value is based solely off of your hidden value and verification value and then change the verification value as well.
It is possible to come up with a computation that will make it rather difficult (but not impossible) to crack this type of verification. However, with the time and effort that would be involved in coming up with such a computation and then staying on top of it to ensure no new exploits come out for it, you would probably be better off just sanitizing the data as you receive it.
In my opinion you are better off not relying on any data received by the user. There are certainly tricks that can be done to do what you ask and this may be one of them but most all of these tricks are ones that can most likely be figured out by an attacker given enough time.
You could see if somebody is changing hidden input elements with Firebug using JavaScript, but the idea sounds silly.
All your critical validation should be done server-side.
You can't rely on anything the client sends being accurate. If somebody really wanted to "mess with your stuff", they could easily (for example) write a Python script to submit data to your server.
Here's a jQuery-based sample of what I was alluding to in my comment:
Live Demo #2
Click Submit: the background will turn green - nothing was changed.
Change the value of a hidden input, click Submit: the background will turn red - something was changed.
HTML:
<form id="myForm" method="post" action="">
<input type="hidden" value="123" />
<input type="hidden" value="456" />
<input type="submit" />
</form>
JS #2:
$('#myForm input[type="hidden"]').each(function() {
$(this).data('originalValue', $(this).val());
});
$('#myForm').submit(function(){
$(this).find('input[type="hidden"]').each(function() {
if ($(this).val() != $(this).data('originalValue')) {
$('body').css('background', 'red');
return false;
}
//just for testing:
$('body').css('background', 'green');
});
return false;
});
There are things you can do in JavaScript, like keeping a copy of the expected value buried in JavaScript:
var originalHiddenFieldValue = document.getElementById("myHiddenField").value;
... later...
if (originalHiddenFieldValue !== document.getElementById("myHiddenField").value)
alert("Hey, stop it!");
At the end of the day though, all the user would have to do is detach any event handlers on your submit button to override any validation and your code would be useless. If they're smart enough to be overriding values using Firebug, you can make a good bet that they'd be willing to go a bit further to modify your scripts too.
If you're trying to check for these things, the only way you can do it with 100% confidence is to check the hidden field server-side, and compare the values, as you have said you are doing anyway.
I've got a form like this:
<html>
<body>
<form onSubmit="alert('Just got submitted');">
<p>
Hello: <input class="field" type="text"/><br/>
Goodbye: <input class="field" type="text"/><br/>
</p>
</form>
</body>
</html>
which in one browser submits happily on user pressing enter from one of the fields, and in another browser, doesn't. Oddly, if I remove the second field, it works in both.
My question is really - is it okay to have a form with no explicit submit element? I really like this behaviour.
Having no explicit submit is poor user experience. Your typical end user has, over the past decade, learned a set of principles for website form interaction. Namely, you can tab between fields, you can select lots of checkboxes, and you have a click a button to actually submit your data.
I've tried developing forms in the past that automatically update with JavaScript, and I got countless complaints from users. They wanted a button or they didn't believe it was working. So in that particular case, I kept the form working as it originally had, but added a submit button that really didn't do anything. They were happy.
These days I just build out my forms with normal submit buttons. Not only do users expect it, but it allows for much cleaner progressive enhancement between non-JS enabled browsers.
It's certainly more than possible to have a form with no submit element, especially if you use JavaScript events to submit the form. I highly suggest you use the onkeypress event to detect the "enter" key being pressed rather than depending on the browser to just accept the "enter" key if you make a form with no submits, to make it cross-browser compatible.
However, I think it's bad form to leave out a submit button of some sort. (It doesn't necessarily have to be an input of type "submit", could be "button" or an image you click.) It's just a standard to have forms that people fill out submitt via a button, and you're taking that away, which could confuse many users who are used to a button. It definitely violates the principles of Don't Make Me Think by presenting an alternate form to the norm.
It's not a good idea. You point out the reason yourself - it doesn't work in all browsers. Also, it's not what people expect, so it may confuse people.
It depends on what you mean with "ok".
If you mean valid (x)html, well it's no problem at all, but on the user side, it's a usability issue. But it also depends on the target audience of your website. If its for tech savvy people, then it's ok.
You could create an input button like this:
<input type="button" onclick("doSomething()") />
The doSomething() would be a function in Javascript that would send your form data to a server-side script. This way you wouldn't have a submit behavior.
Submitting a form on 'Enter' with jQuery?
Also, I'd leave the button in the form, but hide it with javascript ($('#submit').hide()). It means that if the user has disabled script or f.ex. uses some other device, he'll see the default way to submit the form.
If you want to have two buttons which generate two different behavior when submit. what you can so is something like that:
or you can put the form submit inside function1() or function2()
I wrote a AS3 script, basically the script just a form that allow user to enter their email address. After launch the site for couple of months, I found I receive a lots of BOT spammers. I know, 1 way of prevent BOT is using recaptcha thing, beside recaptcha, is there any way to prevent bot to submit my AS3 form??
How about adding an extra input to your form and then hiding it with a CSS style.
Then if the field is filled in, you can be pretty sure it was a bot.
Bots don't generally process CSS rules so they will see the text input and fill it in
Most people have CSS enabled when they browse so they won;t see the text input and it will be blank
For legitimate users that have CSS disabled, you can add a label (also hidden via css) to the text input that tells them what to enter.
e.g. add something like this into your form
<div style="display:none">
<label for="hidden-textbox">What is 10 plus 5?</label>
<input type="text" id="hidden-textbox" name="hdn-txt" maxlength="20"/>
</div>
When you process the form submission:
nothing in the text input is a legitimate user
the value that you told them to enter in the caption is a legitimate user
any value other than empty or your specified value is SPAM and you can discard it
In addition to Nils' excellent answer, see this previous Stack Overflow question for a wide survey of some of the anti-bot measures that are currently popular.
Also, I'm not sure you'll want to use AS3, as that is both server side, and may be more complicated than you need. Still, if you used a Flash app to submit your form (rather than having form information embedded into your HTML), then it would be harder for a bot to parse and submit.