Last modified: 2013-06-18 14:44:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T31410, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29410 - Provide article links to secure counterparts
Provide article links to secure counterparts
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: ssl
  Show dependency treegraph
 
Reported: 2011-06-15 10:39 UTC by Peter Gervai (grin)
Modified: 2013-06-18 14:44 UTC (History)
4 users (show)

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


Attachments

Description Peter Gervai (grin) 2011-06-15 10:39:26 UTC
Per bug 5440 it is pretty easy to fall off the wrong way of secure wikimedia links and end up on an article without SSL, and it is pretty tedious to get back to the secure site: at least I have to either clone a secure window and search for the given article or copy the secure URL and type the article there. 

Looks like an easy hack for a while (until bug 5440 gets fixed, that is just a few years to come) to generate an automagic link to the secure counterpart of any article, with a very small icon or link in the menu. Should be installed on all projects which support secure logins, unfortunately.
Comment 1 Roan Kattouw 2011-06-15 10:43:23 UTC
With a proper HTTPS implementation described in bug 5440 comment 15, this should be moot, right? People will be able to simply change http:// to https:// in their address bar, which is one click and one keypress, and wouldn't fall off secure in the first place thanks to protocol-relative URLs.
Comment 2 p858snake 2011-06-15 10:45:56 UTC
Most people don't really use the secure interface so this would just create even more interface junk which most people don't want. SO could probably make a pretty quick and easy user gadget that provides this functionality.
Comment 3 Peter Gervai (grin) 2011-06-15 11:03:38 UTC
Roan: When? :-)))

snake: your answer depend on depreciating the secure interface, mine on the contrary.
Comment 4 Krinkle 2012-07-20 16:34:23 UTC
Marking worksforme. We no longer support secure.wikimedia.org as we now have HTTPS available on the main domains. And most (if not, all) of the software outputs protocol-relative urls so that you stay on HTTP or HTTPS respectively, based on your current visit.

To allow enforcing of HTTPS dynamically, see also bug 29898. And for other ssl-related bugs, see the tracking bug 27946.

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


Navigation
Links