Skip to content
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

slds aren't handled properly by the 'domain' regexp #5

Open
papandreou opened this issue Oct 17, 2012 · 8 comments
Open

slds aren't handled properly by the 'domain' regexp #5

papandreou opened this issue Oct 17, 2012 · 8 comments

Comments

@papandreou
Copy link
Collaborator

> require('./validation').domain.test('foo.co.uk')
false
> require('./validation').domain.test('foo.uk')
true
@papandreou
Copy link
Collaborator Author

Here's an updated list of "public suffixes": http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1

@Munter
Copy link
Collaborator

Munter commented Oct 17, 2012

@Munter
Copy link
Collaborator

Munter commented Oct 17, 2012

Quite a big list. This is going to add considerable weight.

Worth it though.

@mwoc
Copy link
Collaborator

mwoc commented Jul 21, 2014

This issue happens to be fixed by commit 8db3cf9, though not with the TLD whitelist.

@Munter what's your opinion about closing this issue and instead going with the no-whitelist approach in issue #6?

@Munter
Copy link
Collaborator

Munter commented Jul 21, 2014

I think there are uses cases for both. Ideally I think we should expose a light and a full package. Weight doesn't really matter in node the same way as it does in the browser, so both are valuable imo.

@mwoc
Copy link
Collaborator

mwoc commented Jul 21, 2014

Yeah, in Node it might be useful with a whitelist-based TLD validation anyway, for instance to make sure that a domain could be hosted by a company. In that case the user should probably have influence on the content of the whitelist though, which wouldn't be compatible with how it's done now.

Can you think of any specific use cases where the TLD whitelist can still be purely controlled within the package as it has been done up to now, and is shown in this issue?

New TLDs are added constantly nowadays, so with a whitelist we probably need to release new versions every time a new one is added (whenever https://publicsuffix.org/list/effective_tld_names.dat doesn't give a 304, I guess).
Alternatively, if the whitelist is maintained by the consumer of one-validation, it only has to be updated once that consumer decides to add support for a new TLD.

In the browser the use case for whitelist-based validation is very limited as I see it, especially due to the rate at which new TLDs are added and the use case of being able to send e-mails to TLDs which hit production hours ago.

I think we could offer a generic way of doing plugins in one-validation, and adding the whitelist-based validation based on this issue + the new gTLDs etc. that way. It could of course also be a separate file in the same package, so the users can choose which file to implement.

The main issue is prioritisation. Would it be acceptable if a new version based on #6 is released for now (so without whitelist approach) and that re-implementing the whitelist is postponed until there is time or a strong use case for it?

@Munter
Copy link
Collaborator

Munter commented Jul 21, 2014

I'm not aware of any dependents other than purify and npmjs.org doesn't show a lot of downloads. I think it's ok to pull out the tld whitelist. Just be sure to release a new major version when you do.

@mwoc
Copy link
Collaborator

mwoc commented Jul 21, 2014

Cool thanks, will make sure to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants