Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#2234 closed change (fixed)

Collect emails from a form field on a landing page

Reported by: annlee@… Assignee: sebastian
Priority: P3 Milestone:
Module: Sitescripts Keywords:
Cc: sebastian, saroyanm, trev, fhd, Kai, matze Blocked By:
Blocking: #2213, #2267, #2335, #2436 Platform: Unknown
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):

http://codereview.adblockplus.org/5177883412660224

Description (last modified by sebastian)

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:

emailAn email address to receive the notification about the Adblock Browser iOS launch
langThe 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@…, 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.

Change History (33)

comment:1 Changed 5 years ago by annlee@…

  • Description modified (diff)

comment:2 Changed 5 years ago by annlee@…

  • Blocking 2213 added

comment:3 follow-up: Changed 5 years ago by sebastian

  • Cc sebastian saroyanm trev added
  • Component changed from Unknown to Sitescripts
  • Description modified (diff)

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.

comment:4 in reply to: ↑ 3 Changed 5 years ago by annlee@…

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

comment:5 follow-up: Changed 5 years ago by sebastian

  • Description modified (diff)
  • Ready set

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.

comment:6 Changed 5 years ago by sebastian

  • Priority changed from Unknown to P3

comment:7 in reply to: ↑ 5 ; follow-up: Changed 5 years ago by 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 ?

comment:8 in reply to: ↑ 7 ; follow-up: Changed 5 years ago by 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.

comment:9 in reply to: ↑ 8 Changed 5 years ago by saroyanm

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

Sure, thanks.

comment:10 follow-up: Changed 5 years ago by sebastian

  • Description modified (diff)
  • Owner set to sebastian

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

comment:11 Changed 5 years ago by sebastian

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

comment:12 Changed 5 years ago by sebastian

  • Blocking 2267 added

comment:13 in reply to: ↑ 10 ; follow-up: Changed 5 years ago by trev

  • Cc fhd added

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.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 5 years ago by sebastian

  • Description modified (diff)

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?

comment:15 in reply to: ↑ 14 ; follow-up: Changed 5 years ago by 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."

comment:16 Changed 5 years ago by 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

comment:17 in reply to: ↑ 15 Changed 5 years ago by sebastian

  • Cc Kai added
  • Ready unset

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?

comment:18 Changed 5 years ago by sebastian

  • Description modified (diff)
  • Ready set

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

comment:19 Changed 5 years ago by sebastian

  • Description modified (diff)

Added the text of the verification email as discussed internally.

comment:20 Changed 4 years ago by sebastian

  • Description modified (diff)

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

comment:21 Changed 4 years ago by sebastian

  • Description modified (diff)

Made response texts consistent with #2213.

comment:22 Changed 4 years ago by sebastian

  • Description modified (diff)

Improved specification of email address validation.

comment:23 Changed 4 years ago by sebastian

  • Description modified (diff)

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.

comment:24 Changed 4 years ago by annlee@…

  • Description modified (diff)

comment:25 Changed 4 years ago by annlee@…

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!'

comment:26 Changed 4 years ago by sebastian

  • Description modified (diff)

comment:27 Changed 4 years ago by sebastian

  • Blocked By 2425 added

comment:28 Changed 4 years ago by sebastian

  • Blocked By 2425 removed

comment:29 Changed 4 years ago by sebastian

  • Blocked By 2335 added
  • Description modified (diff)

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.

comment:30 Changed 4 years ago by saroyanm

  • Blocking 2436 added

comment:31 Changed 4 years ago by sebastian

  • Cc matze added

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

comment:32 Changed 4 years ago by sebastian

  • Blocked By 2335 removed
  • Blocking 2335 added
  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:33 Changed 4 years ago by saroyanm

  • Sensitive unset
Note: See TracTickets for help on using tickets.