Respect SS_BASE_URL scheme for builds and tasks that are ran through CLI.

[s-kerdel]

Affected Version

silverstripe/framework 4.10.11 The SilverStripe framework (probably >= 4.*)

Description

The dev/build process executed through CLI does not respect 'https' scheme from environment in a correct way. Due to how HTTPRequestBuilder processes URL's through the HTTPRequest constructor, requests will be using the 'http' scheme by default unless $variables['_SERVER']['HTTPS'] or variables['_SERVER']['SSL'] is set.

The desired execution of dev/build through CLI would be the same way dev/build is executed through the browser for an application with SS_BASE_URL="https://www.example.com" being set in the environment configuration.

Saying that, we currently have an issue of unstyled (static) error pages due to stylesheets and scripts being supplied over http. This is a known issue that describes the problem: silverstripe/silverstripe-errorpage#20
I think the problem is caused because of HTTPRequestBuilder only validating HTTPS scheme based on SERVER variables.

// Set the scheme to HTTPS if needed
if ((!empty($variables['_SERVER']['HTTPS']) && $variables['_SERVER']['HTTPS'] != 'off')
    || isset($variables['_SERVER']['SSL'])) {
    $request->setScheme('https');
}

There are also several other issues semi-related to this change (might have missed some):
#7492
#8028

By setting the SERVER HTTPS scheme variables based on SS_BASE_URL within CLIRequestBuilder I expect to resolve these issues with minimal impact.

Steps to Reproduce

• Setup a new SilverStripe framework project.
• Add the SS_BASE_URL="https://www.example.com" environment variable for your project where HTTPS is enabled.
• Execute the /dev/build?flush=1 command through the web browser navigated using the https scheme, a.e. https://www.example.com/dev/build?flush=1.
• Review the contents of error-404.html or error-500.html and verify the base tag containing a https URL (correct).
• Execute the /dev/build?flush=1 command through the CLI interface having the same SS_BASE_URL value.
• Review the contents of error-404.html or error-500.html and verify the base tag containing a http URL (wrong).

This is a simple example of where the scheme is causing an issue and the impact might be much bigger when running a task from CLI.

Please ask for other required details that are needed to review my change, which I will submit through a pull-request in a minute.

PRs

• FIX Respect SS_BASE_URL scheme in CLI environment #10616

[s-kerdel]

Pull request: #10616

[michalkleiner]

Should we be also setting the host then, not just the protocol, if SS_BASE_URL is defined?

[michalkleiner]

Why is the protocol an issue and not the host? Or does the host get picked up in some other way and the protocol doesn't, meaning the issue could be somewhere else?

[s-kerdel]

Yes, in this case the host is picked up in some other way. The issue is caused by HTTPRequest being initialized with default scheme value set to http. The passed URL is relative to base, thus scheme is stripped by Director::makeRelative in an earlier stage.

SilverStripe has a default fallback of setting HTTP_HOST to localhost when unknown. I would be able to add HTTP_HOST to the condition and assign the base URL to it if that's what you mean, but is there a good way to verify if this is the desired thing to do?

With my change I am trying to keep the impact as low as possible while HTTP_HOST is used in plugins for example (which I am probably not able to test, because I don't have a case yet where I can relate HTTP_HOST being invalid through CLI).

[UndefinedOffset]

Seems like this is related to the issue I've been seeing on Silverstripe Cloud where error pages are generated with a base url of http:// when the domain is set for https only. For anyone on the SS team with access to the ticket system there it's INC-76415.

[GuySartorelli]

This is now fixed in 4.12.1
Thanks @s-kerdel for reporting and fixing this.