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.
5 Likes
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 label must start with a letter or number:
[a-z0-9] - you can have letters, numbers and hyphens in the middle:
[a-z0-9-]{0,61}- double hyphens are allowed
- a label can be up to 63 characters long
- a label must end with a letter or number:
[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
hacky
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.
2 Likes
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.
1 Like
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.
1 Like
Bumping this one again.
Still cannot change website parameter in user profile to new TLDs - tells user the address is invalid.
1 Like
Sure @falco can you add this one to your list please? We should have centralized logic for this check…
4 Likes
This is still an issue for me on latest.
2 Likes
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.
8 Likes
I do not follow, why do we need to validate every domain TLD? Just allow the text pattern…
3 Likes
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?
1 Like
I’m looking at the code right now. The regexp highlighted earlier in the topic is an easy fix.
https://github.com/discourse/discourse/pull/5020
It still needs to pass user website whitelist, if set. I don’t know how often that is set.
6 Likes
Had to fix the regexp as it was allowing “http://https://google.com”
https://github.com/discourse/discourse/commit/e43799134c03d0180ef64dc941f61c26f5219314
8 Likes
Teach me to try to REGEXP at near midnight. 
5 Likes