fix(is_ssl): adds check for ssl when behind a proxy or load balancer

[tbfVladd]

When hosting WordPress behind a reverse proxy or a load balancer and the site URL is configured to start with https (Admin -> Settings -> General -> WordPress Address & Site Address) , it isn't possible to login or view administration due to too many redirects. WordPress gets caught in a redirect loop and the browser shows an error page this effect.

This is caused by the request URI ($_SERVERREQUEST_URI?) being re-written by the reverse proxy or load balancer so the checks in wp-login.php and wp-admin/index.php fail.

However, the convention in this configuration is to set additional HTTP headers which this PR adds a check for.

I've tested this on the latest WordPress docker container behind an nginx reverse proxy.

[tbfVladd]

software patch

[tbfVladd]

correctly named patch/diff file :o)

[swissspidy]

Hi there and welcome to WordPress Trac!

This has come up numerous times in the past, a quick search would have easily revealed that.

There are some discussions in #15733 and #31288 about why this isn't something core intends to do. They also provide suggestions how to address this on your custom environment (e.g. through wp-config)

I'm closing this as a duplicate of the latter as it has most context of the two.

I'd recommend leaving a comment there if you have any new information.

When hosting WordPress behind a reverse proxy or a load balancer and the site URL is configured to start with https (Admin -> Settings -> General -> WordPress Address & Site Address) , it isn't possible to login or view administration due to too many redirects. WordPress gets caught in a redirect loop and the browser shows an error page this effect.

This is caused by the request URI ($_SERVER['REQUEST_URI']) being re-written by the reverse proxy or load balancer so the checks in wp-login.php and wp-admin/index.php fail.

However, the convention in this configuration is to set additional HTTP headers which this PR adds a check for.

I've tested this on the latest ​WordPress docker container behind an nginx reverse proxy.

Trac ticket: https://core.trac.wordpress.org/ticket/61915

[tbfVladd]

Thanks for the reply - sorry, I didn't see it as I was following the contribution guidelines for code and raised a PR.

From the links you've provided, I think I'll do this: https://core.trac.wordpress.org/ticket/15733#comment:1

You should set $_SERVER['HTTPS'] to equal $_SERVER['HTTP_X_FORWARDED_PROTO'] in your wp-config.php file. This isn't an issue for core to solve.

For anyone else reading this, add this to your wp-config.php

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && ('https' === strtolower( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) ) ) {
    $_SERVER['HTTPS'] = 'On';
}

Cheers,

Andrew 🙂

Replying to swissspidy:

Hi there and welcome to WordPress Trac!

This has come up numerous times in the past, a quick search would have easily revealed that.

There are some discussions in #15733 and #31288 about why this isn't something core intends to do. They also provide suggestions how to address this on your custom environment (e.g. through wp-config)

I'm closing this as a duplicate of the latter as it has most context of the two.

I'd recommend leaving a comment there if you have any new information.