Last modified: 2014-11-17 10:34:40 UTC
See https://translatewiki.net/wiki/Thread:Support/Secure_server for a thread on messages in the MediaWiki namespace or in i18n files that allows users to break out from the secure server in a probably unexpected way. Since this is an undesired behaviour, it should be avoided in the conect of WMF servers.
I'm not sure what exactly this bug is requesting be done (Change the english translation of the message, or make the secure set up not suck to say use different secure/non-secure interwikis, or something else...?)
It requests that the secure server links to the secure server under all circumstances.
(In reply to comment #2) > It requests that the secure server links to the secure server under all > circumstances. Thats a nice goal and all, but I'm not sure what specific actionable things are in this bug. A direct link to the non-secure server should always go to the unsecure server (imho), so perhaps making interwikis keep on secure server would be good, and using the foundation: interwiki.
Generated links in messages should be either generated externally to the message using current settings, or generated within the message using {{localurl:}} and such which will generate data with current settings. (A few places that try to cache have historically had problems with this like the site notice, which is why we have to jump through some hoops to have separate ssl/non-ssl caches or whatnot.) However... The link above is about a Wikimedia-specific message which includes a fully qualified link to a particular Wikimedia web site, not a general MediaWiki message that points to another part of the same site. That particular message ([[MediaWiki:Wikimedia-copyright]]) is also a raw-HTML message that's included on every page's footer, so I think there are performance issues with dropping a {{#switch}} into it. The correct fix for this in the long term is to switch it to use protocol-relative links: Text is available under the <a href="//creativecommons.org/licenses/by-sa /3.0/">Creative Commons Attribution/Share-Alike License</a>; additional terms may apply. See <a href="//wikimediafoundation.org/wiki/Terms_of_Use">Terms of Use</a> for details. However, the second one (to wikimediafoundation.org) will not work until new SSL system has been deployed (bug 20643), at least for that site. A possible workaround is to swap the link to secure in JS, but that's nasty. :) Since it's also a read-only page for all but a handful of people, it's not as super important that it be HTTPS; in its current incarnation most folks will not be able to edit on wikimediafoundation.org and won't need to be logged in when they get there -- an HTTPS-only session won't get transferred and won't leak any actual session data to observers. If they're already logged in on non-HTTPS then they'll remain logged in on it, but that doesn't leak anything that wasn't already being leaked if you happened to hit someone else's hardcoded external link during the same browser session.
The dependency should be the other way around: bug 20643 must be done first to make a protocol-relative link work.
Marking as fixed, because most (if not all) links to other WMF sites in MediaWiki messages are now changed to protocol-relative links (although bug 20643 is not yet marked as fixed).
