Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


rlane32 at gmail

Aug 31, 2011, 3:14 PM

Post #1 of 6 (450 views)
Permalink
Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki

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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


brion at pobox

Aug 31, 2011, 3:56 PM

Post #2 of 6 (446 views)
Permalink
Re: Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki [In reply to]

On Wed, Aug 31, 2011 at 3:14 PM, Ryan Lane <rlane32 [at] gmail> 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
Handatlas<https://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
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rlane32 at gmail

Aug 31, 2011, 4:16 PM

Post #3 of 6 (440 views)
Permalink
Re: Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki [In reply to]

> 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
> Handatlas<https://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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


roan.kattouw at gmail

Aug 31, 2011, 9:46 PM

Post #4 of 6 (440 views)
Permalink
Re: Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki [In reply to]

On Thu, Sep 1, 2011 at 12:56 AM, Brion Vibber <brion [at] pobox> 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

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


agarrett at wikimedia

Sep 1, 2011, 8:55 PM

Post #5 of 6 (437 views)
Permalink
Re: Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki [In reply to]

On Thu, Sep 1, 2011 at 4:46 AM, Roan Kattouw <roan.kattouw [at] gmail> 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.

--
Andrew Garrett
Wikimedia Foundation
agarrett [at] wikimedia

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


roan.kattouw at gmail

Sep 2, 2011, 10:14 AM

Post #6 of 6 (432 views)
Permalink
Re: Protocol-relative URLs and HTTPS enabled on foundationwiki and commonswiki [In reply to]

On Fri, Sep 2, 2011 at 5:55 AM, Andrew Garrett <agarrett [at] wikimedia> wrote:
> On Thu, Sep 1, 2011 at 4:46 AM, Roan Kattouw <roan.kattouw [at] gmail> 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 mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.