-
Suggestion
-
Resolution: Unresolved
-
None
-
11
-
Currently, for security reasons, a custom domain must follow the pattern <subdomain>.<subdomain keyword>.<domain>. For example, https://customer.support.acme.com.
(ref: https://support.atlassian.com/organization-administration/docs/add-a-custom-domain/).
However, this is not ideal for customers who want to have a shorter custom domain.
It would be great to have the option to only use one subdomain.
In the meantime, the optional redirect URL can be used when creating the custom domain.
[CLOUD-11811] Ability to have a short custom domain with only only one subdomain
Come on Atlassian. You can and should do better. More transparency please. CLOUD-6999 was open for over 10 years! With no explanation for what was holding up any progress on an important capability to provide normal 2nd level custom domains for your customers.
Now you have provided us a kludgy workaround solution that is not what was asked for and vaguely referred to security concerns for why you can't provide a standard custom domain solution. It's time to come clean. Why specifically can you not provide a standard 2nd level custom domain for your customers?
If I had to guess, I would say the security reasons are due to some extremely embarrassing code debt. I'd also guess, that no one wants to either admit it or attach their name to the reason.
The developers probably wanted to fix this and do it right, but management at software companies will often listen to those who present new flashy dollar generating ideas and ignore those who want to "waste" money on things like code cleanup.
This won't affect them short term as many of us are locked into this product at the moment.
But IMO, long term, the brand/company will feel the negative side effects of upsetting so many people who are the decision makers on choices for software like this.
And for good or bad, us IT, software, devs, etc tend to hold a grudge haha
The "security reason" cited in CLOUD-6999 remains unclear to many observers of the original issue. Could you please provide a more detailed explanation of the rationale behind this decision and clarify the specific attack vector that this measure is intended to protect against?
You can achieve a proper Redirect URL (preserving the path) as well as enforce SSO if you're using Cloudflare or something similar in front of Atlassian. The only downside to this is that the actual URL in the address bar and share links will still be for the fourth-level domain.
We use a Cloudflare Redirect Rule with an expression to concatenate the Atlassian SAML Logon URL (with continue parameter) and the Request URI Path.
concat("https://id.atlassian.com/login/saml/start?connection=saml-GUID-GOES-HERE&application=jira&continue=https%3A%2F%2Fcustomer.support.acme.com", http.request.uri.path)