Even though Discourse is hosted on my new TLD domain ‘jamesnorth.productions’, it will not allow the website ‘http://jamesnorth.productions’ in the user preferences.
It says that the website is invalid.
Version v1.7.0.beta3 +100
Even though Discourse is hosted on my new TLD domain ‘jamesnorth.productions’, it will not allow the website ‘http://jamesnorth.productions’ in the user preferences.
It says that the website is invalid.
Version v1.7.0.beta3 +100
Here is the relevant line
https://github.com/discourse/discourse/blob/1f5325e3f03db06aff71f1e1d9343ee2b7f21ed2/app/models/user_profile.rb#L4
Changing the 2,10 to 2, would permit any length, but not sure if that would be the right modification for this.
I have many questions about that RE.
Here’s a fragment to match a DNS label (other than top-level):
/[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?/i
What it is doing:
[a-z0-9]
[a-z0-9-]{0,61}
[a-z0-9]
The rules for a TLD are the same, except that all numeric is not allowed.
No number in first position (one character label okay): /([a-z]([a-z0-9-]{0,61}[a-z0-9])?)/i
No number in last position (two character minimum): /[a-z0-9][a-z0-9-]{0,61}[a-z]/i
At least one letter in middle part (hacky for making RE readable): /[a-z0-9][a-z0-9-]{1,30}[a-z]([a-z0-9-]{0,30}[a-z0-9])?/i
The hacky one could be rewritten to all compliant strings, but it is ugly to enforce a letter somewhere while also enforcing a length restriction. There will be a ton of |
s in the proper answer.
Combined hostname RE: (labelpart\.)+(tldpart1|tldpart2|tldpart3)
:
/([a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?\.)+(([a-z]([a-z0-9-]{0,61}[a-z0-9])?)|[a-z0-9][a-z0-9-]{0,61}[a-z]|[a-z0-9][a-z0-9-]{1,30}[a-z]([a-z0-9-]{0,30}[a-z0-9])?/i
And final combined WEBSITE_REGEXP:
WEBSITE_REGEXP = /(^$)|(^(http|https):\/\/([a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?\.)+(([a-z]([a-z0-9-]{0,61}[a-z0-9])?)|[a-z0-9][a-z0-9-]{0,61}[a-z]|[a-z0-9][a-z0-9-]{1,30}[a-z]([a-z0-9-]{0,30}[a-z0-9])?\/.*)?$)/ix
(The syntax highlighter gets confused by the “Combined” line.)
Does /x to ruby mean the same as /x to perl? If so, in-line comments and a reformat should be added.
It occurs to me that I stated that correctly, but did not code it correctly. When the dot-com billionaire who remembers his script kiddie roots registers the 1-3-3-7 TLD (for the ‘leet’ email address of i@m.1-3-3-7
), TLD part 3 above would find no letters and deny it. The fix should be obvious.
Just giving this one a bit of a bump.
It seems as though the admin area does allow new TLDs in company domain
and in contact email
.
Are they being validated though, or do they allow anything?
If the former, perhaps whatever that validation is will work perfectly well in the user preferences
area.
Bumping this one again.
Still cannot change website
parameter in user profile to new TLDs - tells user the address is invalid.
Sure @falco can you add this one to your list please? We should have centralized logic for this check…
This is still an issue for me on latest.
Yeah I made a fix to this, but using the current PublicSuffix gem is a memory hog, so we reverted.
Long term, we want to create a optimized PublicSuffix gem to fix this, and will also use it fix here.
I do not follow, why do we need to validate every domain TLD? Just allow the text pattern…
Almost a year later - still the same.
Cannot add new TLDs to personal preference ‘website’ field.
Reckon a plain old text field is all it needs?
I’m looking at the code right now. The regexp highlighted earlier in the topic is an easy fix.
It still needs to pass user website whitelist, if set. I don’t know how often that is set.
Had to fix the regexp as it was allowing “http://https://google.com
”
https://github.com/discourse/discourse/commit/e43799134c03d0180ef64dc941f61c26f5219314
Teach me to try to REGEXP at near midnight.