-
Notifications
You must be signed in to change notification settings - Fork 6.9k
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
Domain should not have '.' restrictions #61
Comments
If you're running locally as a developer then the system will work with just localhost or dockerhost if mapped in your /etc/hosts file. If you deployed via beanstalk then for now you must have a valid domain that is accessed via www.mydomain.com. Currently you cannot have sub-sub-domains so stuff like www.corp.mydomain.com will not work. It's a known issue we're working on to fix. |
I agree ... to first test this amazing product, and/or to use it internally it won't be used on a "root" domain but instead on a sub/sub domain, with a wildcard .... therefore the DNS restrictions are not really compatible currently ;) I would prefer if mattermost could only use the first left part as the "wildcard" DNS part ;) |
It appears that TLD's longer than 3 characters are also invalid. I tried |
Our plan is to make it work with any number of sub-sub-domains. This is a known limitation that we plan to address soon. Currently, you must have a domain that looks like sub.domain.tld or *.example.com. The system also has a special case when it sees the host as localhost or dockerhost it will work in a developer/tester mode. @wedtm there shouldn't be any limitation of only allowing 3 characters on the tld. You should access the site at www.example.ninja then once you create a team you can access the team directly at myteamname.example.ninja. |
I've just submitted a pull request with the changes I needed to make in order to support sub-sub domains. Even if not merged, it may still serve as a template to make your own modifications to get working sub-sub-domains #105 |
+1 |
#200 Will fix this. |
* Revert "[GH-14939] Set defaults on API Config (#61)" This reverts commit c4a03ec * scheduleOnce; testing; wip with tracing statements and retry after failing * remove tracing; cleanup * refactoring; remove callback's error for simplicity; more tests * improve test stability * make api simpler; more tests * linting * refactor; more tests * simplify naming * simplify; turn startup into one call; only one callback allowed * Un-simplify. The multi-step setup is needed. * only one callback supported * improve tests * improve example * closeHoldingMutex -> closeWhileHoldingMutex * PR comments * PR comments * clarify comments * update comments * PR Comments; Close -> Cancel * the linter bails on bad spelling? srsly? Co-authored-by: Alejandro García Montoro <alejandro.garciamontoro@gmail.com>
更新する箇所を間違えていたので修正
There seems to be very hard restrictions how many '.' are allowed in the domain which will always cause problems.
for testing I setup a instance:
dev.example.com, with www.dev.example.com and some other aliases.
when creating the team, the url is configured as
[INPUT] .dev.example
Also the redirect is then to the cut domain. Some TLD only allow second level domains. example.co.uk, also causing problem when running the service as a subdomain.
The text was updated successfully, but these errors were encountered: