Changes between Version 14 and Version 18 of Ticket #2234


Ignore:
Timestamp:
04/16/2015 02:52:16 PM (5 years ago)
Author:
sebastian
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #2234

    • Property Cc Kai added
  • Ticket #2234 – Description

    v14 v18  
    77 
    88=== What to change === 
    9 Implement a WSGI app served by the multiplexer under `/submitEmail` handling email addresses sent as form data in a `POST` request. The email address will be given by the `email` form field (one email address per request). Those email addresses must be stored in a persistent file on the disk, one line per email address (this will be compatible with CVS). Moreover, the file needs to be locked for writing to avoid problems when concurring requests try to access it at the same time. 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. 
     9Implement a WSGI app served by the multiplexer providing following two controllers: 
     10 
     11==== `/submitEmail` ==== 
     12 
     13This controller should handle email addresses submitted in a form field with the name `email` in a `POST` request. A verification email should be sent to that email address. This email must include a link to `/verifyEmail` described below. The email address must also be stored in a way that it can be associated to the verification code given in that link. Once this has been done, a response with the text "Thanks for your submission! You'll receive a verification email shortly." should be sent. 
     14 
     15==== `/verifyEmail` ==== 
     16 
     17This controller should handle the links in the verification emails sent by `/submitEmail`. The verification code will be given in the query string by the parameter `code`. If the verification code is known and can be associated with a previously submitted email address, that address should be marked as verified, and the user should be redirected to a landing page. If the verification code is unknown the user should be redirected to a different landing page.