If this feature is approved, it should be improved to accept multiple domains and to set whether domains are allowed or banned.

yes it should be a - a whitelist/blacklist feature

is this a core feature ?

is this a core feature ?

Imho no. I'm quite sure there exist already 3rd party plugins which do that fine and the use case is quite limited.

I looked and didnt see any

Enhanced to have a list of allowed and disallowed domains could be quite useful

Could be useful in core. But there are free extensions doing feature like this. For example:
https://extensions.joomla.org/extensions/extension/access-a-security/site-access/domainrestriction/

i missed that

I'm going to implement the Whitelis/Blacklist. In my opinion, is useful and necessary this featured inside core.

This featured, It is normal in all kinds of scenarios, such as user registration. I do not think you should install another extension, to have it enabled

Sorry for this, did wrong here

The extension @ot2sen mentioned is mine - I originally wrote it for a school, to limit registrations to employees using a valid school domain. Later I expanded it on user feature requests.

I find that most people use it to blacklist domains, but it can white/black list TLD, Domain, and full addresses. So you could limit registrations to only .CU domains if you wanted....

Thank you again @Quy . Also, i added support for TLD.

Actually I support this for the core. Given Joomla’s user base at present this seems like a logical addition to the core.

there really is no difference to the password limits except now we have some domain limits we already have

Tested here:

1. Creating user in back-end accepts blacklisted domains.
2. Modifying account in back-end also
3. Editing profile in front-end also

I therefore consider this proposal as incomplete.

Thank @infograf768 . What others change can be in this proposal?

To be acceptable, a validation should occur each time the email field is presented to be filled in a form.

First of all: thank you for the contribution! I hate to say that, but at least for me this should not be part of core. Its a 3dp feature, which can easily be implemented using a plugin. We already have enough (confusing) edge case configuration settings.

To be acceptable, a validation should occur each time the email field is presented to be filled in a form.

@infograf768 you mean, validate on the client side too?

First of all: thank you for the contribution! I hate to say that, but at least for me this should not be part of core. Its a 3dp feature, which can easily be implemented using a plugin. We already have enough (confusing) edge case configuration settings.

You welcome @dneukirchen , I glad of contributing to my favorite tool. Hope I can do more. About your opinion, IMHO a lot of things inside Joomla can be as part of a 3dp feature, and not for that, need be out of Joomla. But no problem if this is the reason why this will not be considered to be added to Joomla.

you mean, validate on the client side too?

Here is his previous reply:

Creating user in back-end accepts blacklisted domains.
Modifying account in back-end also
Editing profile in front-end also

In my case, I manage 10 Joomla sites that don't have user registrations so this feature is not applicable.

Thank you @Quy , but I still not understand what mean. Sorry for boring.

In my case, I manage 10 Joomla sites that don't have user registrations so this feature is not applicable.

Well, I decided to make this PR, after found 7 times this request. I read all the comments before about why this featured is not applicable, and is okay if this is a no need. How can I know this decision? Someone on the project come here and close this PR or I need close it?

Editing profile in front-end also

Go to the frontend.
Log in.
Edit your profile.
Change your email address to a blacklisted domain/tld which will be accepted when it should be rejected.

The same applies to the backend.

I got it now @Quy . Thank you, and sorry for no understand before

Added missing validation check when you create/edit a user on the backend. And added missing validation check when you edit a user on the frontend. And sorry again @Quy and @infograf768 for no understand well before when I left this checks out.

test:
issue solved when editing profile in frontend and editing user in back-end, but not when editing account in backend
link is /administrator/index.php?option=com_admin&task=profile.edit&id=122 (where the id is the user id)

The model is /administrator/components/com_admin/models/profile.php

Thank you again @infograf768 . Is done

Even if using two lists, you still need to add an additional option to define default action for domains which aren't on any list. Currently the logic is flawed. Test case:
Add blocked.com to blacklist.
Add allowed.com to whitelist.
Try to register with example.com
The registration will fail even though example.com is not explicitly blacklisted.

Still, I don't think it's correct to have two lists. Unless I'm forgetting some scenario, one list with wildcard support would be better.

But if you define something inside a whitelist, then you are defining the only patterns that are going to be allowed (is how work a whitelist imho). That is why example.com is not allowed. The condition check as first if something is inside of the blacklist and if it matches yours, if not, then go to the whitelist for doing same, but if the whitelist have some pattern inside, all different email domain/tld will fail, because the site only accept one or several specific patterns

Done. Thank you @infograf768

If this PR is accepted, we may think later about adding a check also when entering an address in the mail field for a contact. Not sure if it is necessary.

In the mean while, I think this new feature is nice, simple and should get in.

But if you define something inside a whitelist, then you are defining the only patterns that are going to be allowed (is how work a whitelist imho).

This is true but the same is true for blacklist. Both lists are of equal importance. So, if there's no default option set by the user, you can't prioritize any of the lists in your code. And because of that, any domain that isn't on any list should be neither blocked nor allowed, which makes no sense. So you do need to add default action.

@SharkyKZ @carlitorweb
Afterthought: I think whitelist should have priority. If it is empty, then blacklist should take over.
If it is not empty, a check should be done to make sure the same entry does not exist in blacklist, throw an error if there is one or ignore blacklist if none.

If this PR is accepted, we may think later about adding a check also when entering an address in the mail field for a contact. Not sure if it is necessary.

Good point. I think this field need have the same restriction.

In the mean while, I think this new feature is nice, simple and should get in.

Thank you @infograf768 and for providing a test.

Follow all the opinions of @SharkyKZ, now you can put what restriction you want to use. As @SharkyKZ said, really there is not a scenario where you need use both list. So, one is enough.

I made a commit where you can test this when you create a user inside the backend. If is correct the way, I will make all the change to others place.

I update all the files, for include this new way. Look better now. Thank you @SharkyKZ @infograf768

The same check/code are in 4 places. Can it be done with a single method?

For that, I think need an event inside plugin.user but I do not think this check/code it must be there. Not when the option is controlled by the component.

The PR is now totally broken. Tested with blacklist domain.

Also: $params are missing when editing frontend profile
Also: I suggest the error lang string to be generic, i.e. added in en-GB.ini (front and backend) as

JGLOBAL_USER_MAIL_DOMAIN_NOT_ALLOWED="This email domain <strong>%s</strong> is not allowed"

As far as I can see isssue is that $blackListMailDomain as well as $whiteListMailDomain are not defined anymore.

Tested this OK (Note the single quote for the $optionRestriction value):

			if (!empty(array_filter($listMailDomainTLD)))
			{
				if ($optionRestriction === '2' && !empty(array_intersect($needles, $listMailDomainTLD)))
				{
					$this->setError(JText::sprintf('COM_USERS_REGISTRATION_USER_MAIL_DOMAIN_NOT_ALLOWED_MESSAGE', $userMailDomain[1]));

					return false;
				}
				elseif ($optionRestriction === '1' && empty(array_intersect($needles, $listMailDomainTLD)))
				{
					$this->setError(JText::sprintf('COM_USERS_REGISTRATION_USER_MAIL_DOMAIN_NOT_ALLOWED_MESSAGE', $userMailDomain[1]));

					return false;
				}
			}

Thank you @infograf768 . Now is okay, and added the global string too.

Thank you @infograf768 is done.

I have tested this item ✅ successfully on 8882533

Looks OK now.

@SharkyKZ

Please test again.

I can still register with a blacklisted domain.

How about only show these settings when Allow User Registration is enabled?

Good catch @Quy thank you. I swear I had updated that model with the new changes. Thank you. I test now 10 times, on the administration, and the frontend. Now i not have doubt all work, how need work.

And excellent suggestion, about only show these settings when Allow User Registration is enabled. Is done too.

After considering many options, I think it's best to implement robots.txt-like rules. This would allow for more precise control, including subdomains, wildcard support and user-set priority. And to prevent code duplication, this can be added as an option to EmailRule.

@carlitorweb do you mind if I submit an alternative PR?

@SharkyKZ no problem.