The forceHTTPS cookie is cruft left over from an intermediate stage of the HTTP to HTTPS migration. Usage of forceHTTPS in CentralAuth will break in July 2020 due to a browser policy change which requires all cross-domain cookies to have the Secure attribute.
History
forceHTTPS was introduced in September 2012 rMW5801da5f86e1: (bug 29898) Set cookie to force HTTPS from HTTP to support the wpStickHTTPS checkbox on the login form.
The checkbox was later replaced by a user preference, and MediaWiki::main() checks the preference directly. However, with $wgCookieSecure, the user is not logged in before they are redirected, so the separate cookie needed to be retained. The preference is hidden in WMF production using $wgHiddenPrefs, citing T102245.
CentralAuth also sends a forceHTTPS cookie whenever it sends a session cookie with the Secure option. The core and extension views of the cookie were eventually integrated to fix conflicts between them.
Removal of the forceHTTPS cookie was discussed as part of T110353. The only objection was that someone (outside of WMF) might still want it. I think that is unlikely at this point. Browser vendors are ratcheting up the pressure on web developers to switch to HTTPS. By far the easiest solution for a small wiki is to just switch unconditionally.
Proposal
- Add $wgForceHTTPS. This will make the HTTP -> HTTPS redirect be unconditional.
- Do not send the forceHTTPS cookie when $wgForceHTTPS is true.
Future work
- T118413: Wikimedia wikis should use https:// in $wgServer
- Deprecate $wgSecureLogin.
- Deprecate protocol-relative URLs in $wgServer (T54253)