Show error if default value for Rancher server-url is a local host IP

[cnotv]

Detailed Description Provide insight to the user in case of communication issues with DO instance.

• Add validation to the server URL property both on the setup screen and the global settings page that lets you change it - when set to 127.0.0.1 or localhost, we show a warning banner.
• Text for banner should be: If the Server URL is internal to the Rancher server (e.g. localhost) the downstream clusters may not be able to communicate with Rancher

Context While interacting with a cloud service, if the server-url is not set, requests will hang unfulfilled without a clear message, especially for beginner users.

Displaying a notice if Rancher has not a remote IP, we should inform the user of possible issue, e.g. creation of Clusters.

Configuration path: /c/local/settings/management.cattle.io.setting Area: Global Settings -> Settings -> server-url

[catherineluse]

I think this is a great idea and will help many people who are trying Rancher for the first time.

Here is what should change. When you set up Rancher for the first time, you will see this screen:

Here Rancher uses whatever is in your web browser URL as the default value for the Rancher server URL. And this is often wrong, because if you are running Rancher on localhost, the default value can end up as https://127.0.0.1:8005. This does not immediately cause an error, but it should. Because if the Rancher server URL is localhost, then if you try to create a downstream cluster, the cluster will get stuck pending.

In the above screen, if the default value contains 127.0.0.1, we should show an error that says "If the Rancher server URL is local host, Rancher will not be able to communicate with downstream Kubernetes clusters"

[richard-cox]

We would need a similar mechanism for the server-url setting in global settings.

That has the description below (note the incorrect product name of Explorer).

Default Explorer install url. Must be HTTPS. All nodes in your cluster must be able to reach this.

So would suggest flipping the text from If the Rancher server URL is local host, Rancher will not be able to communicate with downstream Kubernetes clusters to If the Rancher server URL is internal to the host the downstream clusters will not be able to communicate with Rancher

[catherineluse]

The problem with changing the text is that people don't read. This is documented in several places as well, but a lot of times, text just doesn't register.

[catherineluse]

I'm not saying that changing the text is a bad idea, because in fact your version is more technically correct. Just that some people won't read either way

[richard-cox]

I'm only advocating a tweak to the text you suggested (to fix the direction), and that whatever we do on the setup page should also be done in the global settings page.

[nwmac]

In summary:

• Add validation to the server URL property both on the setup screen and the global settings page that lets you change it - when set to 127.0.0.1 or localhost, we show a warning banner.
• Text for banner should be: "If the Server URL is internal to the Rancher server (e.g. localhost) the downstream clusters may not be able to communicate with Rancher"

[cnotv]

As this will touch global settings, I'll proceed after https://github.com/rancher/dashboard/issues/6633 is merged, so I can simply add the setting for this. I'll create a new validation to check if something is local, with the possibility to define true/false.

[richard-cox]

https://github.com/rancher/dashboard/issues/8893 should be tackled at the same time

[momesgin]

As discussed with @nwmac we should not block the submission if the server url is a localhost url, we should only show a warning message. But for the below cases we'll block the submission and show an error message when the server url:

1. is not a url(we reuse the imported library is-url to validate this)
2. is not provided at all
3. is not https
4. has a trailing forward slash

[richard-cox]

This one should go through QA right @momesgin? Our bot should have re-opened it

[momesgin]

@richard-cox that's right, thanks! I moved it to "To Test" state as I discussed it with @gaktive

[aalves08]

Added as possible automation-candidate. Login part could probably be tested with a unit test... Settings page we have several e2e that we could piggy-back on.

[izaac]

The E2E implementation using fixtures was a really good call. Coverage looks good