Problem/Motivation
A client is using webforms to submit applications for course enrolments. In this situation, the email field validation isn't tight enough because it allows email addresses that have a TLD only. The system to which applications are passed implements tighter checks so applications with this issue currently require manual intervention. Adding this option allows the case where a user enters "fred@gmail" as their address to be picked up at submission time, when they can correct it. The application can then progress without delay.
Steps to reproduce
Add an email field to a webform. In a test submission, try entering "fred@gmail" and see that it is accepted without issue. This isn't an issue with the Drupal service, which deliberately and correctly allows such addresses (https://www.drupal.org/project/drupal/issues/2822142), and this feature request should be an option for the same reasons.
Proposed resolution
I have prepared a patch that adds optional validation which requires a second level domain as well as a TLD.
Remaining tasks
Unit tests.
User interface changes
Adds a new 'Must be routable' option to the validation options for an Email address element.
API changes
Data model changes
Adds new properties for whether the check is made ('routable' - boolean) and the error message to be displayed if validation is executed and fails (routable_error - string, optionally including %mail).
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | email_validator_dns.zip | 1.66 KB | jrockowitz |
| #14 | 3173490-14.patch | 9.9 KB | paulocs |
| #2 | Issue-3173490-2-Optional-routable-email-check-8.x-6.x.patch | 3.26 KB | nigelcunningham |
| #2 | Issue-3173490-2-Optional-routable-email-check-8.x-5.x.patch | 3.2 KB | nigelcunningham |
Comments
Comment #2
nigelcunningham commentedComment #3
megha_kundar commentedComment #4
jrockowitz commentedThis issue can be easily solved per element using a #pattern. I am not sure the webform should address this problem.
Should this issue be solved globally?
We could provide a code snippet (via a Recipe) that uses hook_element_info_alter() to add the email domain validation to all email elements. This snippet would be useful to everyone in the Drupal community because it would not be a webform specific solution.
Comment #5
jrockowitz commentedI think this issue should be fixed using a more general solution and global solution.
Someone just posted a great workaround, which could be moved into a dedicated contrib module.
@see https://www.drupal.org/project/drupal/issues/2822142#comment-13833560
Comment #6
nigelcunningham commentedSorry for the delay in replying - not getting notifications for some reason.
The problem with using the global solution is it allows fred@localhost. The use case for my additional option is that there are cases where only routable addresses should be allowed.
Comment #7
jrockowitz commentedI think this should issue should be handled at a global level. Either a website's associated mail server can or can't handle routable addresses.
Comment #8
nigelcunningham commentedHi Jacob.
Sorry if I'm not being clear enough in describing the use case. Let me try again.
A webform was created, allowing users of a website to complete an application to undertake study courses. One applicant accidentally only entered emailaddress@gmail. The address passed validation by Webform but was (rightly) rejected by the external API to which the application was then forwarded. This has led to the assertion that an email field should have the option to reject addresses that aren't routable - realising that there are other cases in which fred@localhost is perfectly fine.
Regards,
Nigel
Comment #9
jrockowitz commentedThe solution provided by #2822142: Introduce a setting to make the top-level domain optional for email validation. will display an email validation error for fred@localhost.
Comment #10
nigelcunningham commentedHi @jrockowitz.
The patch in the related issue isn't going to get applied to core. Would you reconsider applying this one, please?
Comment #11
jrockowitz commentedI think custom code or a dedicated contrib module is the better solution.
Comment #12
berdirYour decision as a maintainer, but I do agree that this would be a very useful feature to have. We frequently have cases where users mistype their mails (e.g. write .c instead of .ch, or forget the TLD entirely, or use dashes instead of ., I've seen everything). That's problematic as you then can't notify them and we often also have issues with integrations in other systems like mailchimp which causes such a subscription to fail with an error.
As for the implementation, you could do
->isValid($mail, new DNSCheckValidation())which does a full DNS check to make sure the e-mail domain is valid.If you decide to reopen then we could look into writing some tests as well.
Comment #13
jrockowitz commentedLets reopen this ticket.
Comment #14
paulocsAdding tests to it.
Cheers.
Comment #15
berdirexample.com specifically will actually not work anymore if you use the DNS verification thing as mentioned in my comment, because example.com does not have a MX record.
Whether or not we do use that approach, might make sense to use an e-mail address that would pass that check I think.
Comment #16
jrockowitz commentedThe patch looks okay.
Personally similar to my thoughts from #7, I would want this to be a global configuration setting under /admin/structure/webform/config/elements. In one place, a site admin can decide how email addresses are validated.
Comment #17
jrockowitz commentedAttached is POC module that overrides the email.validator services and allows custom validation rules to be applied.
This approach to me makes the most sense since most sites would also like to validate user registration email addresses using the same logic.
This approach also validates email addresses entered via the admin UI.
Am I wrong to suggest that this should be handled via a dedicated contrib module?
@paulocs I really appreciate you taking a crack at the patch. While reviewing the patch, can't help but ask should this advanced email validation logic be a dedicated webform-only feature.
Comment #18
paulocsHey Jacob.
No problem. I see that patch #14 must have some improvements as pointed on comment #12 and #16 if we do a DNS verification.
About #17, it is a good idea to have this verification in a separate module because other people will be able to use the DNS verification regardless webform is installed or not.
But I don't know how other popular webforms handle this verification. If they provide this functionality in core I assume that webform module should have this functionality as well.
If you decide to create a another module for that, I can help anyway.
Let's see what other people will say.
Cheers.
Comment #19
jrockowitz commentedI don't have the bandwidth to create and maintain a new module. There are some similar modules available including https://www.drupal.org/project/email_validator
I agree that we need see what other people will say.
Comment #20
jrockowitz commentedI really this email address DNS validation enhancements should be done at a global level via #17. I am going to close this ticket.