Canonical Admin URL - Site Reconfigure Epic

[wezell]

There are a number of problems that we need to solve regarding how dotCMS handles hosts / sites, especially in our cloud environments.

• We need to standardize on the URLs to our administrative tooling so we can possibly route these requests differently, e.g with whitelists and such
• We need a single host to test against when validating dotCMS's admin tooling - it is hard to know what url to test if a customer has many hosts
• We need to be able to automatically add things like no-index header to requests that hit the administrative domains and tooling
• We need to be able to write rules (in dotCMS) that only work for front end requests, e.g. redirect to a canonical domain.
• We do not want our customers /dotAdmin path to be available on their public sites.
• There is no standard way to build a link that can be shared back to dotCMS's administrative screens - we currently do it a variety of ways
• We need a way to determine if a request is a front end request or a back end request - before we begin our processing
• Same as above, we need a very clear way to distinguish between front end and backend logins
• Customers need a way to test hosts before they are live (DNS cutover) without having to edit their hosts files. They can currently do this with site aliases but it would be nice if we automatically added an alias for them to test with.

In order to solve these I propose a few things

• [ ] Force the canonical admin protocol:url:port to be set by environmental variable, otherwise default to https://local.dotcms.site:8443. The configured hostname should be displayed/reflected in the configuration portlet as the "Admin Portal Url". It should not be editable via the UI - only configurable. This property is the protocol:host:port on which the admin tool can be reached.
• [ ] Update the workflow actionlets to use the canonical admin url when building links back to dotCMS
• [ ] Update the UI where we have the api links to include the canonical admin url
• [ ] Force this canonical admin url as the domain for all administrative functions. To do this we need to write code that intercepts requests and if the request's host does not match the canonical admin host and the request is for an administrative function deny it (e.g. no access to /dotAdmin). Additionally, we should automatically add a request.attribute to any request to the canonical admin url that indicates that it is a "backend" request, e.g. REQUEST_BACKEND:true. If this is not set, then backend functions should not work nor should backend assets be accessible.
• [ ] Do not allow API (REST) access to any resource that requires a backend user unless the host is the canonical admin host.
• [ ] Do not allow backend logins from any host except the one in the canonical admin url
• [ ] add a X-Robots-Tag: noindex for any request that is hitting the canonical admin url, or a url that is configured in a SITE_NO_INDEX_PATTERN which would prevent any site that uses dotcms.cloud or dotcms.site from being added to search engines.
• [ ] When accessing front end resources automatically resolve sites based on the siteKey + canonical admin url, e.g. if we had a dotCMS instance with 2 sites, www.customersite.com and intranet.customersite.com and their canonical admin url is prod.customersite.dotcms.cloud then hitting www.customersite.com.prod.customersite.dotcms.cloud would resolve to the first site and intranet.customersite.com.prod.customersite.dotcms.cloud would resolve to their intranet. We would be able to achieve this by wildcarding their *.prod.customersite.dotcms.cloud DNS. Resolving the host this way would allow any new site added in dotCMS to be externally accessible and testable. Another way to do this is to add a random string or 2 word nonsense phrase to each site that could be used to resolve the site.