Re: [Django] #36809: Allow EmailValidator to customize error messages depending on the part that failed validation

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: Daniel E
Type: | Onetti
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Mike Edmunds):

* cc: Mike Edmunds (added)

Comment:

Natalia's proposal would also simplify implementation of #27029 EAI
address validation. (Or help developers who need that functionality sooner
subclass EmailValidator themselves.)

Django already uses "recipient" to mean a complete email address, possibly
including a friendly display name (e.g.,
django.core.mail.EmailMessage.all_recipients()). The official RFC 5322
term for the part before the @ is ''local-part'', but other common terms
are ''user'' (e.g., existing EmailValidator code), ''username'' (e.g.,
Python's email.headerregistry.Address.username), or ''mailbox''. I'd maybe
go with `validate_username()` and `validate_domain()` to align with
Python's email package.
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: Daniel E
Type: | Onetti
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Natalia Bidart):

Thank you Mike for the validation! I appreciate it. Your naming proposal
sounds great!
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:7>

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: Daniel E
Type: | Onetti
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by jaffar Khan):

* cc: jaffar Khan (added)

Comment:

I want to work on this ticket as the current owner seem to no longer
active.
I think it is more genuine way to separate checks of username and domain
as Natalia proposed. I defined two methods **validate_username()** and
**validate_domain()** as:

{{{
def validate_username(self, user_part):
if not self.user_regex.match(user_part):
raise ValidationError(self.message, code=self.code,
params={"value": user_part})

def validate_domain(self, domain_part):
if domain_part not in self.domain_allowlist and not
self.domain_regex.match(domain_part):
raise ValidationError(self.message, code=self.code,
params={"value": domain_part})
}}}

then inside call, I called these two methods and removed the username and
domain checks as it looks no longer necessary:


{{{
def __call__(self, value):
# The maximum length of an email is 320 characters per RFC 3696
# section 3.
if not value or "@" not in value or len(value) > 320:
raise ValidationError(self.message, code=self.code,
params={"value": value})

user_part, domain_part = value.rsplit("@", 1)

self.validate_username(user_part)
self.validate_domain(domain_part)
}}}

I think it will be a more developer-friendly way. Please let me know
whether to create a PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:8>

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: Daniel E
Type: | Onetti
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by jaffar Khan):

I checked **docs/ref/validators.txt**, and there is no description about
methods of classes, so I don't think documentation changes are needed.
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:9>

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: Daniel E
Type: | Onetti
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by jaffar Khan):

I opened a PR [https://github.com/django/django/pull/20616] based on above
description.
There are some linter failures, If the modified changes are acceptable
then I will polish the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:10>

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------

Reporter: Daniel E Onetti | Owner: jaffar
Type: | Khan

Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by jaffar Khan):

* owner: Daniel E Onetti => jaffar Khan

--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:11>

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: jaffar
Type: | Khan
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Mike Edmunds):

Natalia, in attempting to review jaffar Khan's PR, I realized that while I
agree with these statements in theory, I'm having trouble putting them
into practice:

Replying to [comment:3 Natalia Bidart]:
> … Looking at the other validators in this module, there is a clear
pattern of separating parsing, normalization, and validation into distinct
steps or methods, even when the final error surface remains simple.
`EmailValidator` is somewhat inconsistent here: it already decomposes the
value into user and domain components, but does so inline inside
`__call__`, with no clear extension points. Adding a single extra param
addresses the symptom rather than the structure.
>
> I think a more Django aligned approach would be to re-evaluate
`EmailValidator` as a whole and give it clearer, overridable validation
hooks, while keeping full backward compatibility. For example, introducing
explicit methods like `validate_recipient()` and `validate_domain()`,
called from `__call__`, would allow customization via subclassing without
re-parsing the email or wrapping errors. …

I couldn't tell which validators you were referring to that separate
parsing, normalization and validation. EmailValidator follows the pattern
of the RegexValidators: it has some (overridable) regex and list
properties, and it does pretty much ''everything'' in its `__call__()`
method. Unlike the RegexValidators, it also has one extension point
method: `validate_domain_part()` allows replacing the domain validation
logic (but not `domain_allowlist` exceptions or ValidationError
construction). I ''believe'' the intent was to support stricter domain
validation via subclassing (e.g., for users who felt DomainNameValidator
was too lax or wanted to disallow numeric domain literals).

If a refactored EmailValidator looks something like:

{{{#!python
class EmailValidator:
def __call__(self, value):
... # pre-validation omitted
username, domain = value.rsplit("@", 1) # or
self.parse_parts(value) ?
self.validate_username(username, value)
self.validate_domain(domain, value)

def validate_domain(self, domain, value):
if domain not in self.domain_allowlist and not
some_other_logic_on(domain):

raise ValidationError(self.message, code=self.code,
params={"value": value})
}}}

… then the original ticket request to have access to the domain in the
error message ''does'' seem to require wrapping errors (or duplicating
logic from the superclass):

{{{#!python
class EmailValidatorWithBetterErrorMessages(EmailValidator):
def validate_domain(self, domain, value):
try:
super().validate_domain(domain, value)
except ValidationError as error:
# change "code" and add domain to the error params
raise ValidationError(self.message, code="invalid-domain",
params={"value": value, "domain": domain}) from error
}}}

… and substituting the domain validation logic requires duplicating some
of the superclass code:

{{{#!python
class EmailValidatorWithCustomDomainValidation(EmailValidator):
def validate_domain(self, domain, value):
if domain in self.domain_allowlist:
return # duplicate allowlist logic from superclass
if not idna.utils.is_valid_domain(domain):

raise ValidationError(self.message, code=self.code,
params={"value": value})
}}}

… which makes me think I've misunderstood what you were envisioning in
reworking EmailValidator to improve subclassing hooks.
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:12>

[Django]

#36809: Allow EmailValidator to customize error messages depending on the part that
failed validation
-------------------------------------+-------------------------------------
Reporter: Daniel E Onetti | Owner: jaffar
Type: | Khan
Cleanup/optimization | Status: assigned
Component: Core (Other) | Version: dev
Severity: Normal | Resolution:
Keywords: EmailValidator | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 1
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by jaffar Khan):

Thanks Mike for the review. I think defining subclass is not a good option
which makes duplication of code as you describe. Defining explicit methods
like I did will makes the code more readable and will avoid duplication.
In my current PR I made some changes like the methods
**validate_domain()** and **validate_username()** will return boolean so
we need to wrap the methods inside **__call__**. Now I am confused about
do I have to make these two methods to raise **ValidationError** then no
need for wrapping inside **__call__** or left as it is?
--
Ticket URL: <https://code.djangoproject.com/ticket/36809#comment:13>