New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@harisibrahimkv
Contributor

harisibrahimkv commented Feb 18, 2017

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.

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

This comment has been minimized.

@timgraham

timgraham Feb 18, 2017

Member

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

@timgraham

timgraham Feb 18, 2017

Member

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

This comment has been minimized.

@harisibrahimkv

harisibrahimkv Feb 19, 2017

Contributor

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.

@harisibrahimkv

harisibrahimkv Feb 19, 2017

Contributor

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.

This comment has been minimized.

@pope1ni

pope1ni Mar 8, 2017

Contributor

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

@pope1ni

pope1ni Mar 8, 2017

Contributor

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

This comment has been minimized.

@harisibrahimkv

harisibrahimkv Mar 8, 2017

Contributor

@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.

@harisibrahimkv

harisibrahimkv Mar 8, 2017

Contributor

@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.

This comment has been minimized.

@pope1ni

pope1ni Mar 8, 2017

Contributor

Follow the guide in the documentation on deprecating a feature.

@pope1ni

pope1ni Mar 8, 2017

Contributor

Follow the guide in the documentation on deprecating a feature.

This comment has been minimized.

@collinanderson

collinanderson Apr 22, 2017

Contributor

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)
@collinanderson

collinanderson Apr 22, 2017

Contributor

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)

This comment has been minimized.

@collinanderson

collinanderson Apr 22, 2017

Contributor

(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.)

@collinanderson

collinanderson Apr 22, 2017

Contributor

(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.)

This comment has been minimized.

@timgraham

timgraham May 30, 2017

Member

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.

@timgraham

timgraham May 30, 2017

Member

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.

This comment has been minimized.

@collinanderson

collinanderson May 31, 2017

Contributor

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?

@collinanderson

collinanderson May 31, 2017

Contributor

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?

This comment has been minimized.

@timgraham
@timgraham

timgraham May 31, 2017

Member
Show outdated Hide outdated docs/ref/validators.txt Outdated
Show outdated Hide outdated docs/ref/validators.txt Outdated
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

This comment has been minimized.

@timgraham

timgraham Mar 24, 2017

Member

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

timgraham Mar 24, 2017

Member

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.

Show outdated Hide outdated docs/ref/validators.txt Outdated
Show outdated Hide outdated docs/releases/2.0.txt Outdated
Show outdated Hide outdated docs/ref/validators.txt Outdated
@timgraham

This comment has been minimized.

Show comment
Hide comment
@timgraham

timgraham Aug 18, 2018

Member

Closing due to inactivity.

Member

timgraham commented Aug 18, 2018

Closing due to inactivity.

@timgraham timgraham closed this Aug 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment