Page MenuHomePhabricator

Visiting an http address when logged in via https triggers Central Login notification?
Closed, ResolvedPublic


Copying from 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.

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

Version: master
Severity: normal



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 2:14 AM
bzimport set Reference to bz54513.

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 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 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
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

Change 86044 merged by jenkins-bot:
Vary on forceHTTPS cookie

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 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.