Director::forceSSL bug in SilverStripe – how to fix it

Having problems deploying a SilverStripe site behind proxy? This is how the bug was fixed in the case of pelastahelsinkivaaleilla.fi.

Pelastahelsinkivaaleilla.fi is a site to represent what the candidates of the municipal election of Helsinki think of the future of the city’s nature and cultural areas.

The site is built on SilverStripe CMS. When the site was deployed, a problem occurred: the site didn’t direct to the right URL. Google didn’t help much since it turned out that it’s actually a bug in SilverStripe.

The core issue was that the website is behind a proxy server. For some reason SilverStripe isn’t able to connect to a site behind a proxy. Althought the site is forced to direct to HTTPS URL, SilverStripe is fetching the HTTP URL.

This is how the problem was fixed in the case of pelastahelsinkivaaleilla.fi.

Start by modifying the database

The first step was to modify the database. The site had been developed to use HTTP localhost address everywhere.

Stream Editor was used to make the changes to the database. All HTTP URLs were transformed to HTTPS URLs. In addition, all URLs referring to localhost were modified to refer to the network address of the site, in this case pelastahelsinkivaaleilla.fi.

Edit the configuration files

The second step was to modify the configuration files. The site was configurated to prefer the HTTPS address.

After this the live version of the site was turned on as well as Director::forceSSL. The site still didn’t want to force SSL although it was turned on. Some further actions needed to be taken.

Add of piece of code to return null

After further research there seemed to be no choice but to modify the code of SilverStripe itself in order to prevent it from directing the site to HTTP address.

To make the site skip the check whether it wants to return HTTP or HTTPS, the file CanonicalURLMiddleware.php was modified: return null was added in the beginning of a function called protected function getRedirect(HTTPRequest $request).

With this added piece of code, the site returns the same transfer protocol it received, in this case HTTPS.

Supplement the ENV file

The final touch to make the site work as desired, the ENV file was modified. It was supplemented with a trusted proxy IP address and the base URL.

With these changes the pelastahelsinkivaaleilla.fi site no longer directs to HTTP but to HTTPS as it is supposed to.