Force HTTPS Everywhere

[westonruter]

There is a WP Core Trac ticket for enforcing HTTPS everywhere: https://core.trac.wordpress.org/ticket/28521

There is already a degree of this HTTPS-enforcement as part of the whitelist sanitizer which would be more robust than what is possible in core, since core doesn't have access to the DOMDocument response. We could implement some of the ideas from the core ticket while waiting for it to land in core, and add additional enforcement at the sanitizer layer.

Something else to consider is to add an HTTPS proxy as part of the plugin as a fallback in case HTTPS is truly not available. This could be incorporated from the HTTPS Resource Proxy in the Customize Widgets Plus plugin:

When FORCE_SSL_ADMIN is enabled (such as on WordPress.com), the Customizer will load the site into the preview iframe using HTTPS as well. If, however, external resources are being referenced which are not HTTPS, they will fail to load due to the browser's security model raise mixed content warnings. This functionality will attempt to rewrite any HTTP URLs to be HTTPS ones via a WordPress-based proxy.

See https://github.com/xwp/wp-customize-widgets-plus/blob/master/php/class-https-resource-proxy.php

See also issue regarding media in #130, as this may supersede it.

[jwold]

@ThierryA and I had a sync on this and he was able to share additional details. Sharing my notes from that along with a very quick sketch idea.

The work on this is similar to the validation work.

• One part of scope is getting it into WordPress Core; could require more UX work to inform the users about it. There might be a lot of stuff that’s reusable with how the validation work is being done.
• HTTPS for AMP is a requirement; AMP is not valid if it’s not HTTPS. There’s two sections of the work. When the page loads, use the post processor to pickup all the non HTTPS links; an image for example. Try the HTTPS version, if it’s available replace with the HTTPS link in the html so it validates. If not, trigger an error, either replace image with placeholder or trigger an error to the user. That would be the UX part.
• Then second - the validation in the backend, the way validation is done for AMP; it would probably leverage this page or have a page specific to HTTPS that looks the same where you can see there’s an error. It would likely show up as a category of the regular validation work or separate page with similar layout as validation index.
• So it’d be changing current validation layout to add HTTPS or duplicate the layout and modify to accommodate HTTPS warning. Warning less complicated.

[postphotos]

Also, see: https://github.com/xwp/pwa-wp/issues?utf8=%E2%9C%93&q=label%3Ahttps+

[amedina]

@westonruter would it not be good to work on this on the PWA feature plugin side aiming at core integration?

[westonruter]

@amedina yes, that's right.