Add email verification and validity status to email settings page

[lcjohnso]

New Expected Behavior

Since 25 Jan 2024, due to zooniverse/panoptes#4268, new users are required to confirm their email in order to post on Talk. As a result, we would like to provide two capabilities for users on the email settings page (https://www.zooniverse.org/settings/email):

1. Check their email confirmation / verification status.
2. Request a new confirmation email be sent to the user's email address.

Furthermore, email addresses can be marked invalid when an email from Zooniverse is reported as spam, experiences a hard bounce (e.g., user does not exist at stated domain), or the email address is manually marked as invalid via the user admin page. Related to this, we also wish to add the following third capability for users:

3. Check their email validity status (and potentially edit their email if invalid).

Feature Specification

Use the following fields that are serialized into the user api/me response to inform current status:

Email Validity States

• "valid_email": true for valid email address
• "valid_email": false for invalid email address

Email Confirmation / Verification States

• "confirmed_at": null for unconfirmed email address
• "confirmed_at": 2024-01-25 17:33:01 for confirmed email address

Request New Confirmation Email (@zwolf please confirm or edit if below is not correct)

• send POST to https://panoptes.zooniverse.org/users/confirmation
  • similar to how https://panoptes.zooniverse.org/users/confirmation/new page works

Current behavior

Email confirmation status and validity are not currently presented to the user. For requesting new confirmation email: a page exists to make request by submitting an email address (https://panoptes.zooniverse.org/users/confirmation/new) but this page is not obvious or easy to access or find.

Accounts for Testing

On Prod:

• Confirmed User: https://www.zooniverse.org/admin/users/1901126
• Unconfirmed user: https://www.zooniverse.org/admin/users/2698362
• Invalid Email User: https://www.zooniverse.org/admin/users/2698365

On Staging:

• Confirmed User: https://master.pfe-preview.zooniverse.org/admin/users/1326467?env=staging
• Unconfirmed user: https://master.pfe-preview.zooniverse.org/admin/users/1326468?env=staging
• Invalid Email User: https://master.pfe-preview.zooniverse.org/admin/users/1326458?env=staging

[eatyourgreens]

Request New Confirmation Email (@zwolf please confirm or edit if below is not correct)

send POST to https://panoptes.zooniverse.org/users/confirmation
similar to how https://panoptes.zooniverse.org/users/confirmation/new page works

This might need to go into the Panoptes auth client, similar to how email unsubscribe works at the moment. I'm not sure if you can POST to panoptes.zooniverse.org from the API client itself.
https://github.com/zooniverse/panoptes-javascript-client/blob/bef8c4465e12336afbfd56d4ee34088ec5b0f926/lib/auth.js#L328-L339

[zwolf]

Yeah, that's similar. Unlike the /unsubscribe routes that are defined by Panoptes, the /users/confirmation routes are still stock Devise (here).

I can send a (non-JSON) POST to /confirmation with the right payload and trigger a resend. Like so:

curl -X "POST" "https://panoptes.zooniverse.org/users/confirmation" \
     -H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' \
     -d "user%5Bemail%5D=unconfirmedaddress%40test.com"

If that's sufficient, we may not need to override any of the boilerplate. If that's not enough for a front end button, I can customize a route however it needs to be done.

[eatyourgreens]

I took a quick look at the client config, and the auth client actually uses https://www.zooniverse.org in production.

https://github.com/zooniverse/panoptes-javascript-client/blob/bef8c4465e12336afbfd56d4ee34088ec5b0f926/lib/config.js#L3-L8

[lcjohnso]

Screenshots of simplest possible design for new info on email settings page:

Case = Confirmed

Case = Unconfirmed

@seanmiller26 Thoughts / reactions? Alternate suggestions? (Trying to keep it simple, but happy to entertain alternatives.)

[seanmiller26]

Does this page support icons? I see a mail icon below this section, but I'm not sure of its source.

Here are my suggestions including an adjustment to the wording to be more user friendly.

Confirmed:

Unconfirmed:

Invalid:

I could be swayed on the instructions here, perhaps "Check your email above"

[lcjohnso]

@seanmiller26

Re: icons -- I like it, so hope it can be included!
Re: invalid email -- I prefer "Check and update your email address above"

Great! This is ready for implementation -- thanks!

[shaunanoordin]

(I was trying to hack the PJC in PR 7083, but then I realised I should re-examine some of my basic assumptions first.)

@zwolf can you please help me with some questions regarding our API endpoints?

• Q1: for production, does https://www.zooniverse.org/api/PATH map to https://panoptes.zooniverse.org/PATH for all paths?
  • Context: PJC sets the production API host as https://www.zooniverse.org/api. So, all of PJC's prod queries go to e.g. GET www.zooniverse.org/api/users/12345 instead of panoptes.zooniverse.org/users/12345. I'm guessing this alias-ing was initialised during the days when we had to worry about CORS issues between the the www and panoptes subdomains.
• Q1a: specifically, is POSTing to https://www.zooniverse.org/api/users/confirmation the same as POSTing to https://panoptes.zooniverse.org/users/confirmation?
• Q2: similarly, for staging, does https://panoptes-staging.zooniverse.org/api/PATH map to https://panoptes-staging.zooniverse.org/PATH for all paths?

I'm re-examining my assumptions because I've been trying to make PJC send POSTs to https://www.zooniverse.org/api/users/confirmation and https://panoptes-staging.zooniverse.org/api/users/confirmation, and receiving 404s in return. It only occurred to me now that all the examples in this thread only talked about https://panoptes.zooniverse.org/users/confirmation

[shaunanoordin]

Answered on Slack, thanks Zach!

The redirects from www.zooniverse.org to panoptes.zooniverse.org are managed via Front Door. It’s matching /api/* , but there’s also a separate set of redirect rules to handle the devise (non-api) routes at /users/PATH. I think I needed to add /users/confirmation to that list so that it redirects as expected. This is done now.

So, Q1: https://zooniverse.org/api/PATH redirects to https://panoptes.zooniverse.org/api/PATH for all paths.

Q1a: Now zooniverse.org/users/confirmation (no /api/) should redirect to panoptes.zooniverse.org/users/confirmation because I added the new pattern to match above. No /api/ in these URLs because they are Devise routes that are unscoped/outside that namespace.

Q2: Staging works a lil differently since there’s no FD. AFAIK, there’s no redirect from /api/ to / on staging, all panoptes requests should be made to /api/.

[lcjohnso]

Closed by #7083 and #7117