Sent API registration emails contained a typo

[zackkrida]

We recently used a one-off script to send emails to users who had registered for the Openverse API during a time period in which verification emails were broken. Unfortunately, the emails we sent contained broken link with a url with two slashes, like so:

                      error here: ↓
https://api.openverse.engineering//v1/auth_tokens/verify/{mytoken}

We should most likely:

1. Reintroduce the one-off script (it was removed in this PR: Remove one-time-use command #768)
2. Fix the duplicated slash
3. Bonus: The emails were shown to be sent from 'noreply'; ideally we could set a name like 'Openverse API Team' or something in the code. Here's how it looked in Gmail:

Edit: As @sarayourfriend indicated, we can identify the users we emailed in production under the resendoauthverification:processed redis key.

[aod-123]

@zackkrida Are the verification emails still broken? I was attempting to register earlier today and still have not received an email to verify? I've double checked the email address and everything should be good from my end.

[zackkrida]

As far as I'm aware the emails are working, @aod-123. I just tried to register myself and got the confirmation instantly, after running the following command:

curl \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name": "My amazing project", "description": "To access Openverse API", "email": "[email protected]"}' \
  "https://api.openverse.engineering/v1/auth_tokens/register"

[aod-123]

@zackkrida The first email address I tried was for a Google Group/Bot (anything sent to the email address goes to each of our admins emails) and as far as our IT team could tell nothing seems to have come in for that address. I've tried another individual address our company has and it appears to work with that one though it did go to spam right away in GMail. I'm not sure if that would be the reasoning why it didn't come through for the group but I suppose just a heads up that companies with a similar setup may not get the verification email.

Sorry, just a follow up question as well, I noticed the expires_in value is for 10 hours. Does this mean we would need to have a CRON job or something setup to refresh our token every 10 hours? Is there a specific reason it's 10 hours and not 12?

Thanks for your help!

EDIT: Looks like our IT team was able to dig out the email to the first group address. It got caught in the filters due to being seen as spam there as well so just FYI for any GMail users!

[sarayourfriend]

Thanks for the extra information @aod-123, that's very helpful! As for the expiration: I'm not sure why it returns for 10 hours. Frankly, I don't see where in the code we actually assign a specific expiration to tokens. 10 hours does seem arbitrary 🤔

[aod-123]

@sarayourfriend It could be a default value that's just coming through? Might there be any plans for having longer expiration times on the tokens? Or potentially changing it to at least every 12/24 hours or so instead of the 10? For now, I'll need to update our project to refetch a token (authenticate) every ten hours or when a 401 is received. We originally implemented when CC was handling the project and so just needed an API key with no expiry in the past, we didn't realize that our key had no longer been working until the recent change regarding limiting page results.

[sarayourfriend]

It doesn't seem that there's a default value anywhere in the oauth2_provider library code or our own code, which is really what's left me stumped about it 😓 I did not spend more than 10 minutes digging into this though, so there may be an explanation I'm just missing in the code that someone else will uncover.

I am curious about the following, based on what you've shared:

• Do we need token expiry? I suspect we do and that expired tokens, after some time, may indicate a dead application that could be decommissioned after reaching out to the developer.

As for updating the token expiry to be 12/24 hours to match a more consistent cron schedule (for example) makes sense to me. Would you mind opening an issue in this repository for that change @aod-123?

Thanks for your feedback!

[aod-123]

@sarayourfriend Will do and thanks for hearing me out and looking into it a bit!

[sarayourfriend]

Bonus: The emails were shown to be sent from 'noreply'; ideally we could set a name like 'Openverse API Team' or something in the code. Here's how it looked in Gmail:

For this part, we need to update the DEFAULT_FROM_EMAIL environment variable to follow the NAME <EMAIL> format: https://stackoverflow.com/a/2112818