secure.wikimedia.org has interwiki links to insecure sites
Closed, DeclinedPublic

Description

Author: earthengine

Description:
I come from mainland china, where we can not access wikimedia directelly.
However we can access https://secure.wikimedia.org instead, and it works well.

Unfortunately, the interwiki links always link to the normal wikimedia sites. It
is not enough security for users that uses ssl login. It also a bad user
experience for Chinese users behind the GFW, because we have to manually modify
the links shown in the address bar of the browser.


Version: unspecified
Severity: normal

bzimport added a project: HTTPS.Via ConduitNov 21 2014, 9:10 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz5440.
bzimport created this task.Via LegacyApr 4 2006, 4:20 AM
bzimport added a comment.Via ConduitAug 11 2006, 6:24 PM

ayg wrote:

*** Bug 6979 has been marked as a duplicate of this bug. ***

brion added a comment.Via ConduitAug 13 2006, 5:27 PM

May be possible to generate a second set with the alternate links, then load from a different
cache in $secure mode.

AzaToth added a comment.Via ConduitMar 5 2008, 4:38 AM

secure also contains:

		<link rel="apple-touch-icon" href="http://en.wikipedia.org/apple-touch-icon.png" />

and the footer is generated with internal links to en-wiki:
<li id="copyright">All text is available under the terms of the <a class='internal' href="http://en.wikipedia.org/wiki/Wikipedia:Text_of_the_GNU_Free_Documentation_License" title="Wikipedia:Text of the GNU Free Documentation License">GNU Free Documentation License</a>...

Ilmari_Karonen added a comment.Via ConduitMay 22 2008, 5:21 AM

I've written a client-side workaround using Greasemonkey: http://userscripts.org/scripts/show/26924

Works quite nicely, though there are still occasional corner cases that it misses. Also, it would be nice to have an actual list of the wikis available via secure.wikimedia.org and their respective paths. And of course, it would be nice if this bug was actually fixed (though that won't completely obsolete the script, since it also works on hardcoded links in the page content and, if enabled, on links from other sites).

bzimport added a comment.Via ConduitDec 2 2008, 5:03 AM

Wiki.Melancholie wrote:

*** Bug 16432 has been marked as a duplicate of this bug. ***

TheDJ added a comment.Via ConduitJul 25 2009, 6:55 PM

The following can be used in some cases:

{{#ifeq:{{SERVERNAME}}|secure.wikimedia.org

|[https://secure.wikimedia.org/wikipedia/commons/wiki/File:{{PAGENAMEE}} description page there]
|[[Commons:File:{{PAGENAMEE}}|description page there]]

}}

courtesy of User:Dispenser.

demon added a comment.Via ConduitJan 24 2010, 11:43 PM
  • Bug 22255 has been marked as a duplicate of this bug. ***
TheDJ added a comment.Via ConduitMar 3 2010, 1:22 AM

I had forgotten to note here, that the English Wikipedia now has Javascript [[MediaWiki:Common.js/secure.js]] deployed that tries to correct as many links as possible. An ugly work around, but at least it is something.

bzimport added a comment.Via ConduitMar 3 2010, 3:23 PM

joern wrote:

Same in German Wikipedia; seems to fix interwiki links automagically now.

RobLa-WMF added a comment.Via ConduitNov 3 2010, 1:26 AM

Removing the "shell" keyword, since this is marked as blocked by bug 20646, which is a schema change. My understanding of "shell" these days is for bugs that a typical person with shell access can address without making code changes.

Krinkle added a comment.Via ConduitFeb 20 2011, 12:08 AM
  • Bug 27573 has been marked as a duplicate of this bug. ***
Thryduulf added a comment.Via ConduitApr 24 2011, 2:34 AM

I'm viewing from behind a firewall that blocks some pages accessed insecurely (with little logic as to what is blocked). I constantly have to check whether a link is taking me to secure or insecure sites.

grin added a comment.Via ConduitJun 15 2011, 10:30 AM

Yep this is very annoying, since there is no automagic link from insecure site to the same page on the secure one.

I see several bugs mention similar problems, like bug 29053 as well as several duplicates. Is there a hope to change this in mediawiki ("proudly since 2006!") or should we consider javascript hacks permanent, and start deploying them worldwide?

Catrope added a comment.Via ConduitJun 15 2011, 10:41 AM

(In reply to comment #14)

Yep this is very annoying, since there is no automagic link from insecure site
to the same page on the secure one.

I see several bugs mention similar problems, like bug 29053 as well as several
duplicates. Is there a hope to change this in mediawiki ("proudly since 2006!")
or should we consider javascript hacks permanent, and start deploying them
worldwide?

Our ops people are working on a proper HTTPS solution, so people can access the secure sites using URLs like https://en.wikipedia.org instead of the horrible secure.wm.o hack. This will be implemented using protocol-relative URLs (e.g. //en.wikipedia.org/wiki/Foo) for things like images and interwiki links.

grin added a comment.Via ConduitJun 15 2011, 10:47 AM

Well since it's not advised to host different secure hosts on the same IPs (due to braindead browsers apart from many other reasons, for example those listed in bug 20643) I'm not convinced this will happen soon. (At least JeLuf doesn't seem to see the light, and I tend to second his opinion.)

Nevertheless I'd be happy to see which way we're supposed to head and when do we plan to get there, be that the current ugliness or the future beauty. :-P

(And this bug isn't even ASSIGNED, heh.)

Catrope added a comment.Via ConduitJun 15 2011, 11:16 AM

(In reply to comment #16)

Well since it's not advised to host different secure hosts on the same IPs (due
to braindead browsers apart from many other reasons, for example those listed
in bug 20643) I'm not convinced this will happen soon. (At least JeLuf doesn't
seem to see the light, and I tend to second his opinion.)

Nevertheless I'd be happy to see which way we're supposed to head and when do
we plan to get there, be that the current ugliness or the future beauty. :-P

(And this bug isn't even ASSIGNED, heh.)

Well ops is working on getting this done, even though the bug isn't assigned. I'll ask Ryan to respond when he wakes up.

Bawolff added a comment.Via ConduitJun 15 2011, 6:25 PM

To ask what might be a really stupid question... Couldn't the secure site and the non-secure site just use two different $wgInterwikiCache db's? Or would that break in all sorts of weird ways.

Not that it matters much if we're going to get shiny https://en.wikipedia.org style secure sites soon. :D

Reedy added a comment.Via ConduitSep 27 2011, 8:57 PM

New SSL cluster fixes this

Krinkle added a comment.Via ConduitSep 28 2011, 1:21 AM

Reopening. That cluster is not live and even on the wiki's were it's on trial (commons, meta) it doesn't work:

https://commons.wikimedia.org/w/index.php?title=Commons:Sandbox&oldid=60159882
Has a link to [[m:Test]], is not going to https://

Krinkle added a comment.Via ConduitSep 28 2011, 1:22 AM

Removing bug 20646 dependency as this is going to be solved differently (protocol-relative urls inside interwiki table for those that support it, and http or https hardcoded for (third-party) wikis that don't.

Billinghurst added a comment.Via ConduitOct 12 2011, 6:20 AM

With the new relative protocol urls, can this be closed as WONT FIX?

hashar added a comment.Via ConduitFeb 20 2012, 5:18 PM

I am closing this bug since secure.wikimedia.org has been dropped and its functionality replaced.

Using relative URL for interwiki links on WikiMedia website is bug 31327 .

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.