Note that this is not the server-provided session cookie for the user authentication.

Rather, it's a cookie holding a random token to identify the current browsing session (applies to logged-out users as well). Primarily for use by A/B tests and such, though new experiments usually maintain their own session ID.

The {$dbname}mwuser-session cookie is lazily created by mw.user.sessionId() JavaScript. As being generic to MediaWiki, it should not require HTTPS (plain MediaWiki installs work on HTTP as well, such as for local development and most third-party installs).

We could update the mediawiki.cookie javascript library to automatically set the secure attribute for all cookies when on HTTPS. Though that might work unexpected if a wiki supports both. We should probably make it match the server-side behaviour of $wgCookieSecure = 'detect'; which sets the secure attribute on all cookies if the canonical wgServer uses HTTPS. If it uses HTTP or allows both (protocol relative) then it is assumed that cookies are allowed to be shared between them.

In T132993#2216659, @Krinkle wrote:

We could update the mediawiki.cookie javascript library to automatically set the secure attribute for all cookies when on HTTPS. Though that might work unexpected if a wiki supports both. We should probably make it match the server-side behaviour of $wgCookieSecure = 'detect'; which sets the secure attribute on all cookies if the canonical wgServer uses HTTPS. If it uses HTTP or allows both (protocol relative) then it is assumed that cookies are allowed to be shared between them.

+1

if the canonical wgServer uses HTTPS. If it uses HTTP or allows both (protocol relative) then it is assumed that cookies are allowed to be shared between them.

If we start using $wgServer as a way to determine whether a wiki only supports HTTPS, let's remember to update the documentation. I think it's reasonable (we already have way too many HTTPS-related globals) but it might be unexpected for some.

In T132993#2563350, @Nemo_bis wrote:

if the canonical wgServer uses HTTPS. If it uses HTTP or allows both (protocol relative) then it is assumed that cookies are allowed to be shared between them.

If we start using $wgServer as a way to determine whether a wiki only supports HTTPS, let's remember to update the documentation. I think it's reasonable (we already have way too many HTTPS-related globals) but it might be unexpected for some.

Documentation can always use improvement, but we wouldn't be "starting to use" it this way. Per the surrounding comment, we already do this and that's our default behaviour for cookies set from MediaWiki PHP code:

In T132993#2216659, @Krinkle wrote:

[..] We should probably make it match the server-side behaviour of $wgCookieSecure = 'detect'; which sets the secure attribute on all cookies if the canonical wgServer uses HTTPS. If it uses HTTP or allows both (protocol relative) then it is assumed that cookies are allowed to be shared between them.

Well, there must be a time when we started. :) For now I added https://www.mediawiki.org/w/index.php?title=Manual%3A%24wgServer&type=revision&diff=2217974&oldid=2192995; if this meaning of $wgServer is established, this discussion is documentation-only and can continue on the talk page there.

I found it weird that mediawiki.cookie does not honor $wgCookieSecure, as $wgCookieSecure should not be set to true in a mix HTTP/HTTPS configuration anyways. Besides since the introduction of $wgForceHTTPS, mediawiki.cookie should be able to set secure cookies.