Roan sent out a new set of HTTPS fixes today, which made us confident enough to enable protocol-relative URLs and HTTPS on commonswiki and foundationwiki. We haven't purged the cache yet for these wikis, so it's very likely some pages will point you back to HTTP. We'll be purging caches some time soon, but please don't hesitate to try it now. Please file bug reports or let Roan or I know of any issues you find.
Note: there is likely a bunch of site CSS, JS, and templates that will need to be changed to use protocol relative URLs everywhere. HTTPS has a massive long tail :). If you feel like helping out with that, please be bold.
Another *important* note: "Log me in globally" is still actually insecure, even when using HTTPS. It loads the images from each wiki using HTTP, which is what sets your cookies (which are also, then sent over HTTP). If you use this option, people can still steal your cookies; they cannot, however steal your password.
- Ryan
On Wed, Aug 31, 2011 at 3:14 PM, Ryan Lane rlane32@gmail.com wrote:
Roan sent out a new set of HTTPS fixes today, which made us confident enough to enable protocol-relative URLs and HTTPS on commonswiki and foundationwiki. We haven't purged the cache yet for these wikis, so it's very likely some pages will point you back to HTTP. We'll be purging caches some time soon, but please don't hesitate to try it now. Please file bug reports or let Roan or I know of any issues you find.
Cooooooooooool!!!!!!!!!!!
Main thing I notice off the bat is that interwiki links seem to have been set up to use protocol-relative links that don't actually work yet -- at https://commons.wikimedia.org/wiki/Atlas there's a link "Stielers Handatlashttps://en.wikipedia.org/wiki/en:Stielers_Handatlas" which ends up linking to the non-working https://en.wikipedia.org/wiki/en:Stielers_Handatlas
Note: there is likely a bunch of site CSS, JS, and templates that will
need to be changed to use protocol relative URLs everywhere. HTTPS has a massive long tail :). If you feel like helping out with that, please be bold.
Note that existing JS or template code that looks for an 'https' prefix on $wgServer will continue to see the 'https' in 'https://secure.wikimedia.org' but will see only something like '//commons.wikimedia.org' on https://commons.wikimedia.org/
So this should avoid triggering code that explicitly tries to use the secure.wikimedia.org-style alternate paths; but some code that simply decides whether to load from http or https may end up loading things from http by mistake until fixed.
In many cases simply using the '//hostname' style URLs will work fine for both the http://commons.wikimedia.org and https://commons.wikimedia.org -- as long as you don't get ahead of yourself and use it for things that aren't available on https yet. ;)
Most importantly for now, loading images from '//upload.wikimedia.org' should work; loading local JS code from '//commons.wikimedia.org/...' *should* also work.
Please make sure this gets passed around to any commons JS-ers and stylers and templaters to watch out for issues!
Another *important* note: "Log me in globally" is still actually
insecure, even when using HTTPS. It loads the images from each wiki using HTTP, which is what sets your cookies (which are also, then sent over HTTP). If you use this option, people can still steal your cookies; they cannot, however steal your password.
Note that this should get fixed once all the sites are running on https, since we can bump all the cookie-setters onto the current protocol. In the meantime, do consider https://commons.wikimedia.org/ to be very experimental!
-- brion
Main thing I notice off the bat is that interwiki links seem to have been set up to use protocol-relative links that don't actually work yet -- at https://commons.wikimedia.org/wiki/Atlas there's a link "Stielers Handatlashttps://en.wikipedia.org/wiki/en:Stielers_Handatlas" which ends up linking to the non-working https://en.wikipedia.org/wiki/en:Stielers_Handatlas
Gah. I totally forgot about that. Yeah. https on commons is not going to fully work until all other wikis are https'd. I could probably add a hack into the CDB creator to not do this for now, but I think we'll be pushing out support for https everywhere soon, so it's likely a waste of time.
- Ryan
On Thu, Sep 1, 2011 at 12:56 AM, Brion Vibber brion@pobox.com wrote:
Note that this should get fixed once all the sites are running on https, since we can bump all the cookie-setters onto the current protocol. In the meantime, do consider https://commons.wikimedia.org/ to be very experimental!
Depending on where these URLs come from exactly (I forget how CentralAuth obtains them), we could make them use https or be protocol-relative now. That would break this feature temporarily, but in a good way: it would only log you in on other wikis that support https, and wouldn't log yuo in insecurely (or at all) on those that don't.
Roan
On Thu, Sep 1, 2011 at 4:46 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Depending on where these URLs come from exactly (I forget how CentralAuth obtains them), we could make them use https or be protocol-relative now.
It's a list of wiki IDs, and it pulls the appropriate URL from wgServer in the SiteConfiguration arrays.
On Fri, Sep 2, 2011 at 5:55 AM, Andrew Garrett agarrett@wikimedia.org wrote:
On Thu, Sep 1, 2011 at 4:46 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
Depending on where these URLs come from exactly (I forget how CentralAuth obtains them), we could make them use https or be protocol-relative now.
It's a list of wiki IDs, and it pulls the appropriate URL from wgServer in the SiteConfiguration arrays.
Oh, in that case I probably already changed it to pull from wgCanonicalServer instead. Maybe that wasn't the best idea.
Roan
wikitech-l@lists.wikimedia.org