Allow user to re-request account validation email before token expires

[nicholaspcr]

Summary

As pointed out by @kschiffer in https://github.com/TheThingsNetwork/lorawan-stack/pull/6524 when a validation for an user's contact_info/email_address is requested, no other request can be made until the token expires.

Since the default TTL value of the token is 48 hours it would be in the user's interest for us to support re-sending the same validation a few extra times while the token is still valid. That way if by some reason the initial email does not reach the user, the request of another validation email can be done.

Current Situation

We sent a validation request to the email once and can only do it again after the period specified in the is.user-registration.contact-info-validation.token-ttl.

Why do we need this? Who uses it, and when?

It is an edge case but a user might not receive the validation email if:

• The Stack has an internal error while attempting to send the validation email.
• The service used to sent the e-mail fails.

Proposed Implementation

Cache the validation with a short TTL, use it to assert if we should or not send the same email again.

If the email (or a hash of the email) is present in the cache then the validation email was sent recently and it might be sent at maximum of X times, if it is not present then it should only be sent after the token is expired.

Contributing

• [X] I can help by doing more research.
• [X] I can help by implementing the feature after the proposal above is approved.
• [X] I can help by testing the feature before it's released.

Code of Conduct

• [X] I agree to follow TTN's Community Code of Conduct.

[nicholaspcr]

https://github.com/TheThingsNetwork/lorawan-stack/pull/6524#issuecomment-1710292556

@KrishnaIyer replying in here just so we can develop the discussion in this issue.

I said we should rate-limit the RPC, not using the existing rate limiting code. If our current rate-limiting logic doesn't work then we figure something else out. We can think of a max limit of retries per email ID or something. The point is that we don't want bots continuously triggering emails.

I agree with what you said in regards to avoid continuously triggering the emails.

What I proposed in here is to allow the user to retry the RequestValidation procedure, not only a limited amount of times but for limited period of time as well. The reason behind this is to avoid people requesting validation every Y minutes until the token expires which I imagined it could be something a bot would do.

If you think the idea is overkill I'm also down to do a new implementation of the rate-limiting that would take something like email ID as its key. Could be in memory first and could be moved to using Redis by https://github.com/TheThingsIndustries/lorawan-stack/issues/2969, which is on backlog for a while but I've been meaning to pick this up again.

[KrishnaIyer]

Let's keep this simple. What's the problem:

• Users need to wait until the token expires to re-request email.

Simple solution:

• Allow a re-request if the current token expiration time is greater than 30 mins.
• Issue a new token with an expiry of 30 mins.
• That way a user can only request one email every 30 mins.

Something like this both solves the users' problems and we prevent spam. If we want to reduce this window to 15 mins or something based on how customers use this, thats fine.