Allow trusted hosts to be configured with the installer

I guess we want to add some test coverage for that bit of code as well.

Being bold setting this to critical, but having just installed beta 15, my status reports shows that the "Trusted Host Settings" is "Not enabled". This is surely critical as it states:

• This can lead to security vulnerabilities.
• It is highly recommended that you configure this.

Isn't this trivial to configure in the installer, by setting "trusted_host_patterns" in settings.php to the base URL, and localhost?

I assume a lot of people won't be happy with a new critical so close to the intended RC1 release date, but this is a great usability improvement, especially for those new to Drupal.

This is not a security issue, and calling it a security improvement is borderline. I'd say this is a feature request, but leaving for now.
Also all patches are against the dev branch, we can't change beta15.

I'd like to have a possibility for configuring the trusted host at install process. But it should be optional for several reasons I can imagine.
On a second step it would be fine if this setting is changeable. There could be a textfield where the actual host can used as default value.

Another idea is a support for CLI installation. But for this it's easy to create a drush command based on site-alias domain setting.

RTBC +1

Also: this really feels like a UX bug.
The current situation is directly opposed with D8's goals for increasing adoption and improving UX.
Immediately upon install, every user will be faced with the menacing error message
"One or more problems were detected with your Drupal installation."
Then, upon clicking through, they're sent to an esoteric explanation of a complex topic, with the actual solution buried 2 screens down.
All this confusion could have been avoided if the installer had simply detected or asked what the user to provide a base url.

Yeah I have to agree with #11.

Ideally you shouldn't need to google a problem as soon as you've installed new software.

Yes there is a help message: "The trusted_host_patterns setting is not configured in settings.php." but at first contact (with Drupal) the user won't know where this file is or what it's for. A red error message will make them feel like something is very wrong and will likely assume their installation process, hosting config or something external to the software is possibly creating a conflict or is at fault.

If trusted_hosts being unset isn't a problem or should be optional then surely it makes sense to remove the warning/error and lower the warning level on the status page notification to prevent users thinking their installation is broken or they're doing something wrong.

More than a year since Drupal 8 stable dropped, and still the first thing a new admin sees is a bright red error message.

Maybe changing this issue to a UX bug will get it some more attention.

I agree this doesn't look good on installs but I can't commit it without regression tests.

We also need to bear in my mind that a fair few hosters don't allow settings.php to be written during an install. See parts of #2156401: Write install_profile value to configuration and only to settings.php if it is writeable for a long and big discussion of this.

Thank you, everyone, for working on this issue. @alexpott, @catch, @cottser, @xjm and I considered this issue and agreed this should be a major priority task in the install system.

The patch in #1 no longer applied to 8.4.x. A reroll with no further modifications is attached.

I agree with the issue.

But what we describe and agree on the intended behavior, and add it to the issue summary, before posting patches?

I think it is important that a user sees what will be registered as trusted host pattern.
I don't think the installer should do this silently.

Easy solution

Provide a checkbox in the installer: "Only allow requests from detected.hostname.com. This setting can later be changed in the settings.php under $settings['trusted_host_patterns']."
The checkbox could be enabled by default.

Advanced solution

Let the installer show a form element, where a user can define which hosts should be trusted.
This should be pre-filled with the host from the current request.
It could be a textarea, where each line is a host.
Initially, this will not use regular expressions, but the plain host as-is. So it would say "example.com", not "^example\.com$".

There could be a checkbox or something to switch this to regular expression mode.
But maybe this is not even needed. People who need those could do it in settings.php directly.

Add a description / help text, explaining that this will be converted into a regular expression in the settings.php, allowing to add additional trusted hosts later.

The attached patch serves as a proof of concept to extend the functionality of the installer's SiteConfigureForm.php class. It enables the site installer to easily add domains to the trusted_host_patterns found in the settings.php file. The idea came from comment #22 which is mentioned below.

Advanced solution
Let the installer show a form element, where a user can define which hosts should be trusted.
This should be pre-filled with the host from the current request.
It could be a textarea, where each line is a host.
Initially, this will not use regular expressions, but the plain host as-is. So it would say "example.com", not "^example\.com$".

There could be a checkbox or something to switch this to regular expression mode.
But maybe this is not even needed. People who need those could do it in settings.php directly.

Add a description / help text, explaining that this will be converted into a regular expression in the settings.php, allowing to add additional trusted hosts later.

Initial Criteria

In order to ensure a developer-friendly experience while maintaining usability for first-time Drupal installation, I have compiled the following criteria for consideration:

1. The installation input text area is not required.
2. Multiple trusted host patterns could be added on install.
3. Some initial testing to see if the domain is relevant.
4. Allow domains like localhost could be added.
5. Noncomplex patterns can be added see these examples.
6. Automate characters like ^,$,/.

Current solution

The installation screen

Results in the settings.php

$settings['trusted_host_patterns'] = array (
  0 => '^localhost$',
  1 => '^testing\\.domain\\.com$',
  2 => '^domain\\.com$',
);

Know Issues

I'm currently experiencing difficulty in finding a solution to prevent two "\\" from being written into the settings.php in the trusted_host_patterns array. It appears that the SettingsEditor::rewrite applies a regular expression and adds an another forward slash. However, it is not clear to me how this happens.
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

SettingsEditor::rewrite($settings_path, $settings);

The second main issue relates to the permission settings of the settings.php file. During the installation process, the code requires write permissions to be granted. However, it is necessary to overwrite the existing permissions using PHP and then reset them again so that the trusted_host_patterns array can write to the file. I can't seem to find another solution to resolve this without changing the permissions and don't know if it's good practice.

        $settings_path = $this->sitePath . '/settings.php';
        chmod($settings_path, 0744);
        SettingsEditor::rewrite($settings_path, $settings);
        chmod($settings_path, 0444);

The bot didn't recognize "recognise" in the translation strings.