Last modified: 2013-06-18 15:45:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5440 - secure.wikimedia.org has interwiki links to insecure sites
secure.wikimedia.org has interwiki links to insecure sites
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Low normal with 8 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6979 16432 22255 27573 (view as bug list)
Depends on:
Blocks: ssl
  Show dependency treegraph
 
Reported: 2006-04-04 04:20 UTC by Earthengine
Modified: 2013-06-18 15:45 UTC (History)
24 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Earthengine 2006-04-04 04:20:07 UTC
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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-11 18:24:42 UTC
*** Bug 6979 has been marked as a duplicate of this bug. ***
Comment 2 Brion Vibber 2006-08-13 17:27:04 UTC
May be possible to generate a second set with the alternate links, then load from a different 
cache in $secure mode.
Comment 4 Carl Fürstenberg 2008-03-05 04:38:29 UTC
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>...
Comment 5 Ilmari Karonen 2008-05-22 05:21:22 UTC
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).
Comment 6 Melancholie 2008-12-02 05:03:44 UTC
*** Bug 16432 has been marked as a duplicate of this bug. ***
Comment 7 Derk-Jan Hartman 2009-07-25 18:55:53 UTC
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.
Comment 8 Chad H. 2010-01-24 23:43:52 UTC
*** Bug 22255 has been marked as a duplicate of this bug. ***
Comment 9 Derk-Jan Hartman 2010-03-03 01:22:13 UTC
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.
Comment 10 Jørn Martin 2010-03-03 15:23:35 UTC
Same in German Wikipedia; seems to fix interwiki links automagically now.
Comment 11 Rob Lanphier 2010-11-03 01:26:28 UTC
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.
Comment 12 Krinkle 2011-02-20 00:08:35 UTC
*** Bug 27573 has been marked as a duplicate of this bug. ***
Comment 13 Chris McKenna 2011-04-24 02:34:53 UTC
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.
Comment 14 Peter Gervai (grin) 2011-06-15 10:30:37 UTC
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?
Comment 15 Roan Kattouw 2011-06-15 10:41:27 UTC
(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.
Comment 16 Peter Gervai (grin) 2011-06-15 10:47:28 UTC
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.)
Comment 17 Roan Kattouw 2011-06-15 11:16:37 UTC
(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.
Comment 18 Bawolff (Brian Wolff) 2011-06-15 18:25:01 UTC
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
Comment 19 Sam Reed (reedy) 2011-09-27 20:57:05 UTC
New SSL cluster fixes this
Comment 20 Krinkle 2011-09-28 01:21:23 UTC
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://
Comment 21 Krinkle 2011-09-28 01:22:29 UTC
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.
Comment 22 billinghurst 2011-10-12 06:20:58 UTC
With the new relative protocol urls, can this be closed as WONT FIX?
Comment 23 Antoine "hashar" Musso (WMF) 2012-02-20 17:18:49 UTC
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 .

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links