Prevent users from reusing a banned email after account is purged

[jdavcs]

Implements #19095

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. enable new config option, add a list of banned emails
  2. try to register using a banned email (for gmail, try inserting periods and using plus addressing)

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[jdavcs]

Test failures unrelated.

[bgruening]

Would it make sense to consolidate this with the email-domain-blocklist?

[jdavcs]

Would it make sense to consolidate this with the email-domain-blocklist?

I don't think so. The application of the domain blocklist rule is contingent on the existence of the allowlist - i.e., by specifying an allowlist we block everything else, which makes the blocklist useless, which is why it is ignored in such cases. Thus, if we had "foo.com" in the allowlist, we couldn't block [email protected].

Could we change this logic and process the blocklist regardless to weed out exceptions? Sure. But, I think, that would lead to a more complex implementation: we'd have to combine the allowlist/blocklist logic with the banned emails logic - the ordering, as well as processing the domain part and the local-part of each entry. Whereas keeping them separate, I think, keeps the logic simple: first check if the actual email is banned, then process allow/block domain lists.

For the admin, I think having 2 lists, one of blocked domains and one of blocked addresses, should be easier to manage than a combined list of domains and addresses, even though it's two files instead of one. Duplication of domains across lists is not an issue. To me, the following looks more difficult to manage than two separate lists (see how domains and emails are interspersed after a sort):

another-bad-domain.com
[email protected]
bad-domain.com
[email protected]