Fixed #26423 -- Match email validation with html. #8081

harisibrahimkv · 2017-02-18T08:55:39Z

References #7742.

Adds documentation describing what the Validation logic is based on.

Ticket: https://code.djangoproject.com/ticket/26423

timgraham

Release notes in docs/releases/2.0.txt that explain the ramifications of this backwards incompatible change are also needed.

timgraham · 2017-02-18T11:45:28Z

django/core/validators.py


    def __init__(self, message=None, code=None, whitelist=None):
        if message is not None:
            self.message = message
        if code is not None:
            self.code = code
        if whitelist is not None:
-            self.domain_whitelist = whitelist
+            pass  # deprecated


Not sure about the decision here -- documentation/explanation is needed.

According to https://html.spec.whatwg.org/multipage/forms.html#valid-e-mail-address, the text after @ can be a letter, digit or hyphen optionally followed by a . and a trail of letters, digits or hyphens.

The domain whitelist was there to allow domains that don't have a . in them to be treated as a special case (and be allowed). However, since the validation now considers a . as optional already, we don't have to specify any whitelists manually.

If this is the case, there needs to be a proper deprecation warning issued here.

@pope1ni Should I add the deprecation warning within validators.py itself? If yes, is there a specific format that I should do it in? I've added it to validators.txt already.

Follow the guide in the documentation on deprecating a feature.

My thinking was:

Originally django didn't allow any dotless domain names.

People wanted to use "localhost", so domain_whitelist was added to allow more user-specified domains. https://code.djangoproject.com/ticket/4833

We're changing the behavior of email validation to make it allow a lot more email addresses including all dotless domains, so you don't need to specify specific domains to allow.

So before this change, we allow all domains in domain_whitelist, and after this change we allow all domains in domain_whitelist (plus more)

(though I don't know, maybe it still makes sense to deny dotless domain names. I think we denied them because the spec said we should (see ticket 4883). html's validation allows them.)

My question was about the fact that you marked domain_whitelist as deprecated in a comment but didn't implement a deprecation. Did you intend to do some more implementation? Would it be better to remove domain_whitelist so that developers are alerted to the fact that this parameter no longer has any effect? That seems more friendly than raising a deprecation (which might be silent) about it. I doubt that parameter is used in third-party apps where multiple Django version support might be important.

Hmm... I personally really don't like backward incompatibilities, but removing it seems outright fine to me. Though I'm thinking it might be helpful to propose it on django-developers first. Should I do that?

Sure, feel free to continue the thread, https://groups.google.com/d/topic/django-developers/ASBJ0ge2KYo/discussion.

timgraham · 2017-02-18T11:46:38Z

docs/ref/validators.txt

+    The :class:`EmailValidator` works in accordance with the HTML5 Email
+    validation standard as described `here`_.
+
+    .. _here: https://html.spec.whatwg.org/multipage/forms.html#valid-e-mail-address


link "HTML5 Email validation standard" and chop "as described here".
Add a versionchanged annotation as described at https://docs.djangoproject.com/en/dev/internals/contributing/writing-documentation/#documenting-new-features.

ChillarAnand · 2017-02-19T12:25:08Z

docs/ref/validators.txt

+
+        In older version, Email validation was done with Django's own
+        logic. It uses the HTML5 Email validation standard from 2.0
+	onwards.


Reflow this line?

What would sound better?

Since 2.0, Django uses the standard HTML5 Email validation logic.

In the above paragraph, onwards. is just hanging in the last line. It is better if that can be reflowed to previous line.

Okay. Does Since 2.0, Django uses the standard HTML5 Email validation logic. sound better than

In older version, Email validation was done with Django's own logic. It uses the HTML5 Email validation standard from 2.0 onwards.

?

First version is fine. Just rearrange it to

In older version, Email validation was done with Django's own logic. It uses the HTML5 Email validation standard from 2.0 onwards.

Also squash everything to a single commit. There shouldn't be any merge commits. Thanks.

Also change "Email" to "email" in both sentences - don't capitalise.

timgraham · 2017-03-24T17:07:35Z

django/core/validators.py


    def __init__(self, message=None, code=None, whitelist=None):
        if message is not None:
            self.message = message
        if code is not None:
            self.code = code
        if whitelist is not None:
-            self.domain_whitelist = whitelist
+            pass  # deprecated


What's implemented now doesn't look like a deprecation since the domain_whitelist attribute is gone and if a custom whitelist is passed, it's ignored. Anyway, a warning should be raised about the deprecation indicating that whitelist is ignored and will be removed in a future version if that's the intention.

timgraham · 2017-03-24T17:08:25Z

docs/ref/validators.txt

+        logic. Since version 2.0, it uses the HTML5 email validation
+        standard.
+
+	The ``whitelist`` attribute is deprecated since 2.0. It was


Should be documented under .. attribute:: whitelist -- although it's removed so maybe it should be deleted instead.

timgraham · 2017-03-24T17:09:27Z

docs/releases/2.0.txt

@@ -206,7 +206,7 @@ URLs
 Validators
 ~~~~~~~~~~

-* ...
+* The :class:`django.core.validators.EmailValidator` now uses the HTML5 email validation standard.


Wrap documentation at 79 characters -- not sure I'd consider this a "minor feature" though.

timgraham · 2017-03-24T17:14:26Z

docs/ref/validators.txt

@@ -145,6 +145,23 @@ to, or in lieu of custom ``field.clean()`` methods.
        ``['localhost']``. Other domains that don't contain a dot won't pass
        validation, so you'd need to whitelist them as necessary.

+    The :class:`EmailValidator` works in accordance with the `HTML5 email


It would be appropriate to explain this design decision.

I've just added the explanation to the versionchanged annotation.

timgraham · 2018-08-18T13:21:31Z

Closing due to inactivity.

timgraham reviewed Feb 18, 2017

View reviewed changes

ChillarAnand reviewed Feb 19, 2017

View reviewed changes

maxnordlund mentioned this pull request Mar 16, 2017

Fixed typo in email validation regular expression #8187

Closed

timgraham reviewed Mar 24, 2017

View reviewed changes

collinanderson and others added 3 commits April 22, 2017 19:40

Fixed #26423 -- Match email validation with html

5392ed3

Fixed flake8 and syntax errors

13a48b6

Added documentation for the change in EmailValidator logic

50e41fd

timgraham closed this Aug 18, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixed #26423 -- Match email validation with html. #8081

Fixed #26423 -- Match email validation with html. #8081

harisibrahimkv commented Feb 18, 2017 •

edited

timgraham left a comment

timgraham Feb 18, 2017

harisibrahimkv Feb 19, 2017 •

edited

ngnpope Mar 8, 2017

harisibrahimkv Mar 8, 2017 •

edited

ngnpope Mar 8, 2017

collinanderson Apr 22, 2017 •

edited

collinanderson Apr 22, 2017

timgraham May 30, 2017

collinanderson May 31, 2017

timgraham May 31, 2017

timgraham Feb 18, 2017

ChillarAnand Feb 19, 2017

harisibrahimkv Feb 19, 2017

ChillarAnand Feb 19, 2017 •

edited

harisibrahimkv Feb 20, 2017

ChillarAnand Feb 21, 2017 •

edited

ngnpope Mar 8, 2017

timgraham Mar 24, 2017

timgraham Mar 24, 2017

timgraham Mar 24, 2017

timgraham Mar 24, 2017

harisibrahimkv Apr 6, 2017

timgraham commented Aug 18, 2018

Fixed #26423 -- Match email validation with html. #8081

Fixed #26423 -- Match email validation with html. #8081

Conversation

harisibrahimkv commented Feb 18, 2017 • edited

timgraham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harisibrahimkv Feb 19, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

harisibrahimkv Mar 8, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

collinanderson Apr 22, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChillarAnand Feb 19, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChillarAnand Feb 21, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timgraham commented Aug 18, 2018

harisibrahimkv commented Feb 18, 2017 •

edited

harisibrahimkv Feb 19, 2017 •

edited

harisibrahimkv Mar 8, 2017 •

edited

collinanderson Apr 22, 2017 •

edited

ChillarAnand Feb 19, 2017 •

edited

ChillarAnand Feb 21, 2017 •

edited