Collect emails from a form field on a landing page

[annlee@adblockplus.org]

Background

There is an email form field at the bottom of the landing page in issue 2213, in which people can submit their emails in order to get advance notice of the iOS browser launch.

The current plan is to notify people just once prior to the official announcement of the iOS browser.

We can wait until shortly before we notify people to access the addresses, which means I would only need to access the email addresses once.

What to change

Implement a WSGI app served by the multiplexer providing following two controllers:

/submitEmail

This controller handles POST requests with following form fields:

email	An email address to receive the notification about the Adblock Browser iOS launch
lang	The language code of the landing page shown after verifying the email address

If the email address is invalid a response with status 400 and the text "Please enter a valid email address." should be returned. We don't need full email validation here, but should merely make sure that the value is in the form of local@domain where the local part must be ASCII-only. Also no newlines must occur in the value, after stripping leading and trailing whitespaces.

Otherwise, a verification email should be sent to that email address. The sender of the verification email should be ​info@adblockplus.org, its subjects should be "Please confirm your Adblock Browser notification" and following text should be used in the email body:

Hello,

Thanks for signing up to get notified of the Adblock Browser iOS Launch!
Click the link below to verify your email address.

<verification URL>

You can simply ignore this email if you didn't sign up.

If at any point you decide that you no longer want to be notified, email
info@adblockplus.org and we'll remove you from the notification list.


The Adblock Plus Team

Eyeo GmbH
Im Klapperhof 7-23
50670 Cologne, Germany

E-mail: info@adblockplus.org
Web: https://eyeo.com | https://adblockplus.org

VAT-ID: DE279292414
District Court Cologne: HRB 73508
Managing Directors: Wladimir Palant & Till Faida

The placeholder <verification URL> must be replaced with a link to /verifyEmail which is described below. Once the verification email has been sent, a response with the text "A confirmation email has been sent. Please check your email and click the confirmation link." should be returned.

/verifyEmail

This controller handles the links in the verification emails sent by /submitEmail. If the verification URL is valid, the email address should be stored, and the user should be redirected to the corresponding landing page (#2335) in the given language. Otherwise, a response with status 403 and a corresponding error message should be returned.

[sebastian]

What is supposed to happen when the email address was stored? Is it sufficient to return a plain text response with english-only text? This is what the contact form on eyeo.com does. And I am opposed to implement a nicely designed HTML page here. That would belong into the website. So if we really need that, I suggest to issue a redirect back to a page on the website.

[annlee@adblockplus.org]

Replying to sebastian:

What is supposed to happen when the email address was stored? Is it sufficient to return a plain text response with english-only text? This is what the contact form on eyeo.com does. And I am opposed to implement a nicely designed HTML page here. That would belong into the website. So if we really need that, I suggest to issue a redirect back to a page on the website.

is something like this possible? (this was @sven's suggestion)

it's similar to the contact form on eyeo.com, but the difference is that the "Thank you for your submission!..." text replaces the form field and button, instead of appearing below it

[sebastian]

I just checked again how the contact form on eyeo.com is actually integrated. If JavaScript is enabled the form is submitted with an XMLHttpRequest and the response text is nicely shown below the form (it can be styled without any restrictions there). However, if JavaScript is disabled the form still works but the user is redirected to the plain text response. Sounds good to me. So let's do it the same way here.

[saroyanm]

Replying to sebastian:

I just checked again how the contact form on eyeo.com is actually integrated. If JavaScript is enabled the form is submitted with an XMLHttpRequest and the response text is nicely shown below the form (it can be styled without any restrictions there). However, if JavaScript is disabled the form still works but the user is redirected to the plain text response. Sounds good to me. So let's do it the same way here.

Please note that in comparison with eyeo.com we will need translation as well.
So I think we will use the response text only in case the JavaScript is disabled on user side and show the hidden block with success message in case of successful XMLHttpRequest response. Not sure if that worth the effort to also translate the response text.

BTW: Did you referring to the ​current page implementation ?

[sebastian]

Replying to saroyanm:

Please note that in comparison with eyeo.com we will need translation as well.
So I think we will use the response text only in case the JavaScript is disabled on user side and show the hidden block with success message in case of successful XMLHttpRequest response. Not sure if that worth the effort to also translate the response text.

Not having the response text translated here, but only showing it to users without JavaScript, while showing a translated message when handling the response with XMLHttpRequest sounds good to me. But note that you must handle the status code of the response, showing an error message if it's not 200.

BTW: Did you referring to the ​current page implementation ?

Yes, that is what I were talking about.

[saroyanm]

But note that you must handle the status code of the response, showing an error message

Sure, thanks.

[sebastian]

I changed the path of the script to /formsubscribe for consistency with /formmail.

[trev]

Replying to sebastian:

I changed the path of the script to /formsubscribe for consistency with /formmail.

"formmailer" is a common term. I think the original suggestion (/submitEmail) makes more sense, /formsubscribe is just weird.

I realized that we will be putting unverified email addressed into that list, is this really a good idea? I think we need to send people an email and only add the email address if they click a link there.

Finally, does this really belong in the sitescripts repository? fhd wanted to keep functionality related to Adblock Browser out of it for now, we can have external web handlers. The code itself doesn't seem to mention Adblock Browser, so if the commit message doesn't do it either this should be fine.

[sebastian]

Replying to trev:

Replying to sebastian:

I changed the path of the script to /formsubscribe for consistency with /formmail.

"formmailer" is a common term. I think the original suggestion (/submitEmail) makes more sense, /formsubscribe is just weird.

Fair enough.

I realized that we will be putting unverified email addressed into that list, is this really a good idea? I think we need to send people an email and only add the email address if they click a link there.

Yes, we are storing unverified email addresses. However, email verification would add unneeded complexity, requires additional designs and texts, and would ultimately reduce the number of users going through the process of submitting and verifying their email address.

Is there a particular reason, you think we have to make sure that the email address exists and belongs to the user who submitted it, before sending the actual notification? Shouldn't make any difference whether sending a verification email or the actual notification to an unverified email address, right?

Finally, does this really belong in the sitescripts repository? fhd wanted to keep functionality related to Adblock Browser out of it for now, we can have external web handlers. The code itself doesn't seem to mention Adblock Browser, so if the commit message doesn't do it either this should be fine.

Yes, the code doesn't mention Adblock Browser, neither did I plan to mention it in the commit message. So what are we talking about here?

[trev]

Replying to sebastian:

Is there a particular reason, you think we have to make sure that the email address exists and belongs to the user who submitted it, before sending the actual notification?

Complying with various anti-spam laws?

Yes, the code doesn't mention Adblock Browser, neither did I plan to mention it in the commit message. So what are we talking about here?

Should be fine I think, but I think fhd should be aware of this.

One more conceptual issue:

Once the email address were successfully stored a response with the text "Thanks for your submission! We'll notify you before the launch." should be sent.

@annlee: This seems silly, what exactly are we thanking for? Also, people want
to be notified when we launch, not before that. How about: "Your email
address has been recorded, we will notify you when we launch."

[philll]

By Ann-lee:
Replying to trev:

Once the email address were successfully stored a response with the text "Thanks for your submission! We'll notify you before the launch." should be sent.

@annlee: This seems silly, what exactly are we thanking for? Also, people want
to be notified when we launch, not before that. How about: "Your email
address has been recorded, we will notify you when we launch."

'Thanks for your submission' is a standard response in this situation, we're thanking them for taking the time to signup and show their interest in our product.

On the landing page, the text right next to the email form field says, "Get an exclusive heads-up, in advance of the launch".
As such, we do plan to notify them before the launch, I don't know exactly how much in advance, an hour or a couple hours before perhaps, something to be worked out by PR. The targets of this email signup are 'early adopters' who would appreciate being the first to know

[sebastian]

Replying to trev:

Replying to sebastian:

Is there a particular reason, you think we have to make sure that the email address exists and belongs to the user who submitted it, before sending the actual notification?

Complying with various anti-spam laws?

It seems that a double opt-in isn't legally required. But the problem is that with a single opt-in you can't be sure whether the submitted email address belongs to the user who opted in:
​http://de.wikipedia.org/wiki/Opt-in#Deutschland

@Kai: Can you please advice?

[sebastian]

As discussed internally, we need a double opt-in to avoid spamming users who didn't submit their email address themselves. Otherwise we would risk legal issues and might upset users. I have updated the issue description accordingly, and uploaded an updated patch for review. But we still need:

1. A text for the verification email (this would be English-only as we don't have a mechanism for translations here).
2. A landing page for users who clicked the verification link with a valid verification code. Those users will receive the actual notification later.
3. A landing page for users who clicked the verification link for the second time or went to the verification URL directly without a valid verification code.

@saroyanm, @annlee

[sebastian]

Added the text of the verification email as discussed internally.

[sebastian]

Updated verification email text as discussed internally. Updated functional description according to changes requested in the review.

[sebastian]

Made response texts consistent with #2213.

[sebastian]

Improved specification of email address validation.

[sebastian]

I agreed with saroyanm to return an error response directly, rather than redirecting to a landing page, when the email verification fails, since all verification links we issue stay valid forever now.

[annlee@adblockplus.org]

I removed the 'beta' from the first sentence, since iOS will not be launching as a beta, but as a regular/stable launch

before:
'Thanks for signing up to get notified of the Adblock Browser iOS Beta Launch!'

now:
'Thanks for signing up to get notified of the Adblock Browser iOS Launch!'

[sebastian]

As discussed with trev, /submitEmail now also expects a language which is considered for the landing page the user is redirected to, after clicking the verification link.

[sebastian]

The patch just landed in the sitescripts repository.

@palant, matze: Can one of you setup the server, preferable now, that we can do some somke testing?

​https://hg.adblockplus.org/sitescripts/rev/b50182bc254e