On Fri, Jun 17, 2011 at 3:29 PM, Roan Kattouw <roan.kattouw(a)gmail.com>wrote;wrote: Is there a handy config snippet people can use to test things against their local installs in the meantime? -- brion

On Fri, Jun 17, 2011 at 3:42 PM, Roan Kattouw <roan.kattouw(a)gmail.com>wrote;wrote: Great that we have a list! :D Do make sure that all of those individual settings get tested before touching the production cluster; I'd be particularly worried about the possibility of exposing '//domain/something' style URLs into output that requires a fully-clickable link. It looks like wfExpandUrl() *does* correctly expand protocol-relative URLs against the current $wgServer setting, so a lot of things that already expect to handle path-relative URLs should already be fine. But some like the interwikis may be assuming fully-qualified URLs; for instance on API results those should probably return fully-qualified URLs but they're probably not running through wfExpandURL. ApiQueryIWLinks for instance returns interwiki links retrieved via $title->getFullURL(); for interwiki cases this takes whatever was returned by $interwiki->getURL() (which would in this case presumably be the '// fr.wikipedia.org/wiki/$1' form) and passes it back, without making any attempt to expand it further. This'll probably need refactoring to that getLocalURL() handles the regular interwiki URLs, then in getFullURL() we go ahead and call that and pass the result through wfExpandUrl(). -- brion

On Fri, Jun 17, 2011 at 4:02 PM, Roan Kattouw <roan.kattouw(a)gmail.com>wrote;wrote: IIRC testwiki shares a lot of infrastructure and common configuration with the rest of the sites, so unless it's been given an isolated set of config files & interwiki database files, still be careful. :) Almost everything in web UI should be pretty much fine yes -- I really mean things where the URL ends up someplace *outside* a browser, directly or indirectly, and then needs to be resolved and used without the browser's context. Places you definitely want some full URLs include: * api * additional specialty APIs (say, movie embedding links) * feeds (in at least some places) * email * export XML that contains URLs for files or pages There may be other things that we just haven't thought of, which is why I wanted to raise it. Also worth checking for! I'm less worried about those though since the worst case result is "status quo". :) -- brion

On Fri, Jun 17, 2011 at 4:15 PM, Victor Vasiliev <vasilvv(a)gmail.com> wrote: The current case is that you get whatever was the current setting on the web server at the time the email got formatted (which usually means, either HTTP or HTTPS depending on *someone else's usage*) or it defaults to HTTP for something formatted from default. Currently MediaWiki doesn't have a native notion of multiple hostname/protocol availability and it's done by lightly patching configuration at runtime when loaded over HTTPS. Unless something is added, that'll continue in the same way. My personal preference would be to run *all* logged-in activity over HTTPS, so every mail link etc should be on SSL. But I think that's still a ways out yet and will need better SSL acceleration; poor Ryan Lane will kill me if I keep pushing on that too soon! ;) -- brion

Actually, this is exactly what I want. I think we can do it fairly cheaply, but before I commit to that I'd like to test the cluster thoroughly. One thing to note about this cluster is that is a SSL termination cluster, and as such, MediaWiki will have no idea that the user is coming via HTTPS in the normal way. The SSL termination cluster will set a header to indicate the user is coming via HTTPS, so we'll need to deal with that on the MediaWiki side so that we send secure cookies. There's a bunch of things that we should likely do in the future as well. We should likely set a non-secure cookie for HTTPS logged in users that indicates the user requests HTTPS only (via a preference, enabled by default), that will redirect them to HTTPS if they somehow arrive at an HTTP page. Strict Transport Security (STS) should also be a consideration at some point in time, at least for users that have already logged in. This doesn't protect the user from initial site spoofing attacks, but could protect against later spoofing attacks (thanks Aryeh for this idea). I don't think we'll ever get to a point where we can/should use HTTPS for all anon users, but SPDY could be a consideration in the future for anons. After I finish HTTPS I may look at setting up SPDY for testing. - Ryan

On Sun, Jun 19, 2011 at 2:35 AM, MZMcBride <z(a)mzmcbride.com> wrote: We even have a component for it now ;p