Last modified: 2013-10-24 21:23:17 UTC
Copying from https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=574338454#Log-in.2FLog-out.2C_Skins_problem though this seems to cover two aspects: Upper right corner: Cologne Blue skin not showing, notice appears "CENTRAL LOGIN. You are centrally logged in as Carrite. Reload the page to apply your user settings." Which doesn't work. Log-out fails. Ridiculous. 24.20.128.148 When I get this message, I wait a few seconds then hard-refresh the page (it's Ctrl+F5 in Firefox). That usually fixes it. —Redrose64 I believe loading any page would apply settings, not just reloading the previous one, but I may be wrong. —πr2 Small guess, the JS that does the login redressing only works for Vector and Monobook. And it seems there is a problem that every time you visit a http address while logged in over https, you get the 'central login, you are centrally logged in as' notification for every page view. I'm seeing this as well right now. —TheDJ
What it sounds like is happening is that the login cookies are being set as secure, but the forceHTTPS cookie isn't being set so reloading doesn't result in a redirect to https. I suspect this may have been fixed with Gerrit change #85776, which will be deployed along with 1.22wmf19 (see https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule). Unless Chris is going to include it with his CentralAuth deploy later today, in which case it might go out sooner.
I just hit this bug myself. I was logged in via HTTPS, but every time I go to http://meta.wikimedia.org/ it leaves me on the HTTP site and logs me in via Central login. I have both the metawikiforceHTTPS and forceHTTPS cookies set to true. Here are all the headers from the Request and Response: Response Headers Accept-Ranges bytes Age 30292 Cache-Control private, s-maxage=0, max-age=0, must-revalidate Connection keep-alive Content-Encoding gzip Content-Language en Content-Length 16558 Content-Type text/html; charset=UTF-8 Date Wed, 25 Sep 2013 22:24:33 GMT Last-Modified Wed, 25 Sep 2013 13:59:37 GMT Server Apache Vary Accept-Encoding,Cookie Via 1.1 varnish, 1.1 varnish X-Cache cp1054 hit (15), cp1068 frontend hit (2123) X-Content-Type-Options nosniff X-Powered-By PHP/5.3.10-1ubuntu3.6+wmf1 X-Varnish 2043118996 3533212360, 1488879432 1469275617 X-Vary-Options Accept-Encoding;list-contains=gzip,Cookie;string-contains=metawikiToken;string-contains=metawikiLoggedOut;string-contains=metawikiSession;string-contains=centralauth_Token;string-contains=centralauth_Session;string-contains=centralauth_LoggedOut;string-contains=mf_useformat;string-contains=stopMobileRedirect;string-contains=forceHTTPS Request Headers Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding gzip, deflate Accept-Language en-US,en;q=0.5 Cache-Control no-cache Connection keep-alive Cookie metawikiforceHTTPS=1; forceHTTPS=1; stopMobileRedirect=true; centralnotice_bucket=0-4.2; mediaWiki.user.sessionId=ox79ZiUXx2F4mdQgHKLUS2NBGB34Iut6; uls-previous-languages=%5B%22en%22%5D; optin=beta Host meta.wikimedia.org Pragma no-cache User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Change 86044 had a related patch set uploaded by CSteipp: Vary on forceHTTPS cookie https://gerrit.wikimedia.org/r/86044
Change 86044 merged by jenkins-bot: Vary on forceHTTPS cookie https://gerrit.wikimedia.org/r/86044
Actaully, it looks like MobileFrontend has already setting forceHTTPS in the XVO list. So it seems like Varnish isn't respecting that?
I talked with Mark about this. Since varnish ignores XVO, we need a specific VCL rule for varying on forceHTTPS. Mark added https://gerrit.wikimedia.org/r/#/c/86268/1 to do that.
Varnish ignores XVO, so the solution is to try to reproduce XVO in static Varnish configuration? So does that mean it's also ignoring other cookies specified in XVO, such as metawikiLoggedOut, centralauth_LoggedOut, mf_useformat, and stopMobileRedirect that are in the header quoted in comment 2?
That is my understanding of it.
I confirmed with mark that Varnish is handling all non wikipedia (and non ipv6/https) traffic, and I haven't seen anyone complaining about this issue again. So I think the varnish change successfully prevents the issue. Please reopen if anyone sees this happening again.
