Validation Package - Email validation

[ivanbacher]

aurelia/packages/validation/src/rule-provider.ts

Line 311 in 2fca6ea

const emailPattern = /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

Not sure if this is the intended behavior.

At the moment the behaviour is like this

test -> not valid
test@ -> not valid
test@test -> valid
test@test. -> not valid
[email protected] -> valid

Should test@test also not be valid?

If yes, then changing the regex to something like this:

^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*\.[a-zA-Z0-9]{2,}$

Should fix it.

[BBosman]

Technically test@ai is a valid email address.

It's called a dotless domain.

But they're rare and advised against by ICANN (among others), so you could indeed argue that calling them not valid makes more sense.

[Sayan751]

Note that this email pattern is similar to what is there for au1, and only provides a rudimentary email validation. An actual RFC 5322, and RFC 6532 compliant email address parser is a non-trivial job, and IMO is immensely difficult to handle only using regex (disclaimer: I wrote a parser). I think that it is best to remove this OOTB rule from the validation package, so that devs can choose a fitting parser for email-address validation.

[Swarga-codes]

Can we use npm package validator.js to fix the issue?

[aniketkumar7]

Yes, I think emailPattern does not enforce the presence of a top-level domain (TLD) at the end of the email address. This causes emails like test@test to be considered valid, even though they are missing a TLD (e.g., .com, .net, .org, etc.).

To fix this issue, the updated emailPattern adds .[a-zA-Z0-9]{2,} at the end of the regular expression.
Is this enough?
Can I contribute/change it?

[Sayan751]

Can we use npm package validator.js to fix the issue?

@Swarga-codes The general idea is not to create dependency on third party library when it is avoidable. However, if there is a separate package that integrates the @aurelia/validation with a third party library like validator.js (something like @aurelia/validation-validator-js), I have nothing against that. @bigopon What do you think?

Can I contribute/change it?

@aniketkumar7 Please feel free. Thank you for expressing your interest. However, as I have expressed before, my preference would be to remove the email rule, so that devs can choose a more competent email-address validation library as per their preference. An RFC compliant validation of email addresses is a very hard job for a regex.

[bigopon]

integrates the @aurelia/validation with a third party library

We cannot cover all libraries, and providing an official one with a library will limit the potential of others, I think we should have a doc section for integration instead. It's harder to keep it up to date, but these libraries shouldn't change too fast, at least for now.

[Sayan751]

So we agree on removing the email rule 😛

I think we should have a doc section for integration instead.

We already have: https://docs.aurelia.io/aurelia-packages/validation/defining-rules#associating-validation-rules-with-property