Move email verification from client to server

[vladikoff]

When a user gets a "verify account" email and navigates to it we should use the fxa-content-server server to perform the verification instead of front-end app.

Here's the current logic "front-end" logic:

fxa-content-server/app/scripts/lib/fxa-client.js

Line 338 in 9cbf5d9

verifyCode: withClient((client, uid, code, options) => {

and https://github.com/mozilla/fxa-js-client/blob/746abf79745d9825c1f0f180d15519e1983ca95f/client/FxAccountClient.js#L269

The server should perform the same request as the fxa-js-client request above ^. (use the auth url from config, stored in https://github.com/mozilla/fxa-content-server/blob/master/server/lib/configuration.js#L155 )

Ref: #4476 (comment)

[vladikoff]

TODO (first attempt at this):

• Intercept the /verify_email url call (URL provided to you in the email or mail_helper) by creating a new route handler. See example linked below for a custom route handler....

• use the got request library to make a request (example:

  fxa-content-server/server/lib/routes/post-metrics-errors.js

  Line 8 in f9006d4

  const got = require('got');

  and

  fxa-content-server/server/lib/routes/post-metrics-errors.js

  Line 68 in f9006d4

  got.post(sentryConfig.endpoint + '?' + newQuery, {

• After verification on the server show the normal "Verified" view of the front-end app. Check what changes are required on the front-end to avoid errors...

After:

• Implement a TIMEOUT value
• Log verification errors to Sentry...

[shane-tomlinson]

Re-opening since we removed server side verification due to rate-limiting.

[shane-tomlinson]

I can imagine us getting around the rate limiting by using a shared secret between the customs and content servers.

We also have to consider how to handle marketing email-opt ins. A flag is sent to /verify_email when doing client side verification, but AFAICT we lost this with server side verifiation.