Show HN: Add forms to your static site – no iFrames required (opens in new tab)

Best and simplest trick I've found for this is having a CSS hidden honeytrap field, something like <input name="message_body" type="text" class="hideme" />

Bots will put something in the field but humans should never see it, so if the server sees anything in there it can safely toss the whole thing.

Thanks! :)

As many have asked, at least for now there's no real spam protection. Asking you to confirm email for every email/referer pair prevents me from adding your email to zillion sites (although confirmations could also get annoying at that point :) and spamming, but of course that doesn't still prevent bots from filling out your form.

I think in a way it's a tradeoff between ease of use, both for you and the visitor. Alternatively we could do heavier registration process and/or let you configure some running on our server, but then setting things up wouldn't be as easy and you might as well just run your own backend. For the visitors forms provide an easy (than, say just email) way to reach out. I guess the question is, do you prefer false positives (spam) or false negatives (folks not reaching out) :)

Regarding having clear text emails in the source, I'd argue (based on nothing but anecdotes) it doesn't matter, much. As throwawaymsft said elsewhere, bots are pretty good at figuring out what "you (at) email (dot) com" means, so in most cases you'd anyway be getting much spam. We considered a token-based approach instead, but decided to go all-in for simplicity. Also, since we're using forms anyway, they're more likely source of spam than some bot crawling just for addresses.

How I handle it. Effective so far... http://img42.com/881bp

It's a protocol-relative URL, which inherits the protocol of the parent page.

http://www.paulirish.com/2010/the-protocol-relative-url/

Ah, I had the opposite remark:

On http://www.formspree.com/ at section 1, they say to use "http://api.formspree.com/your@email.com" while it should be "//api.formspree.com/your@email.com".

I just set up a Jekyll site with links to youtube and disqus. Quite important or it won't work.

By removing the scheme from the url, the browser will use http/https based on the scheme of the containing page.

That's known as protocol relative URLs. That way if your static page is HTTPS the form action will be the right protocol.

This is what I was thinking as well. An account isn't even necessary, just have a two step process on Formspree.

1. Enter your e-mail address. Click next.

2. Copy the generated code, //api.formspree.com/Kn2JanlPkZ into your form as the action. Obviously this code and e-mail combination is then stored in the Formspree database.

These are for static websites. The idea of an "account" doesn't make sense.

Edit: Ah, you mean that formspree should allow site owners to create accounts. Carry on.

Alternatively, formspree could publish a public key which you could use to encrypt your email address. To make it easy, they would just have a form on their website which does the encryption for you, giving you the opaque string to use in your form.

The UX for the user is the same if Formspree were to just generate a random token and store in their DB mapping it to an email, but this way Formspree doesn't need to store anything in their DB.

The whole static site craze is a rerun of the 90's.

Right? This is the one I switched to after getting fed up with FormMail. It was self-hosted and runs on PHP instead of CGI, whohoo! Pratically magic for 2001. http://regretless.com/scripts/scripts.php#dodosmail

I could be wrong, but it looks like it requires CGI

That's how my very first website worked, which let users vote for Coke or Pepsi. I would get emails during the week and then update the count on the site manually. Horribly inefficient, but as a kid I thought it was pretty great.

I'm probably missing something obvious but I don't understand how this is different apart from costing money

Seems like an enourmously awesome solution, but, again, I ask: who are the users of these kind of services (BitBaloon, Formspree etc.)?

(or, better asked: what is the problem these solutions solve?)

Or more importantly, to stop someone sending an email to N different emails just 1 time?

EDIT: Okay, I missed the part where the email must be registered with them. Assuming no one is interested in spamming with the confirmation email, which seems fair.

Rate limiting per IP would be pretty easy to implement.

Point of interest, it's actually "Referer" - a misspelling that dates back to the original HTTP RFC 1945.

See http://en.wikipedia.org/wiki/HTTP_referer

Oops, good catch, thanks! Hadn't thought of this.

Apparently the problem is just sending a request https->http. https->https should work fine. Adding SSL asap.

EDIT: now you can also use https://api.formspree.com/your@email.com

Originally, I did just that with my service. The problem is when you need simple information like "What browser and version are you using" when someone says something "isn't working". Capturing User Agent during form submission takes an otherwise painful step out: asking a non-technical person to find out what version of Internet Explorer they are running. There are still people who think "The Internet" is "the Blue E on my computer". Similarly adding required fields like "What's your site's address" when you run a multi-site service. All valuable things to have specified so that you can answer any questions with the first response rather than having to ask a pile of followup questions when customers don't provide enough info.

With a general purpose email, you don't get that.

I would assume this product really comes in handly when you really want to add some structure to the data that's being submitted.

Not any more than using an email like:

firstname@domain.com firstletterlastname@domain.com Firstname.lastname@gmail.com

Look, spam happens (unless you obfuscate your address to be unmemorable or unprofessional). Modern email filters are pretty good.

No more so than a company's email being in a Contact Us page.

Oh man, there are HUNDREDS of "scripts" that do this! Here's the PHP one I used to use back in 2004.

http://regretless.com/scripts/scripts.php#dodosmail

I'm surprised this is being touted as such a new idea, but I guess with static sites making a comeback, it was inevitable.

I'd advise against making it a total submissions limit. I would not bother attempting to use a service that is guaranteed to blow up on me one day even if the site remains low traffic.

It seems to me that would be so much more useful than a bunch of emails.

Or expose an API for a CSV download, or a data feed, or something.

This kind of service will stay low on the radar compared to how many people write their email in plain text on web pages. It's quite unlikely that someone is going to crawl the web and harvest formspree "ACTION" fields when they can simply harvest regular email and get a million more.

I guess you could use a new email address that automatically forwards what it receives to multiple emails.