Page MenuHomePhabricator

forceHTTPS cookie not deleted in Wikimedia environment
Closed, ResolvedPublic

Description

When a user logs out on a single wiki (not included in a wiki farm) the forceHTTPS cookie is deleted. In the Wikimedia environment, login.wikimedia.org sets top-domain forceHTTPS cookies (.wikipedia.org, .wikiversity.org, etc) which are not deleted when the user logs out and therefore s/he is still redirected to HTTPS as anonymous user; even if s/he logs in again after having unckecked the preference "Always use a secure connection when logged in" s/he still is redirected to HTTPS since the global forceHTTPS cookie is still here. So these global forceHTTPS cookies should be deleted when the user logs out. The relevant HTTP headers are:

Login from the specific wiki (here frwiki):

Set-Cookie: frwikiforceHTTPS=true; expires=Sat, 28-Sep-2013 00:49:37 GMT;

path=/; httponly
Continuation of the login, from login.wikimedia.org:

Set-Cookie: frwikiforceHTTPS=1; expires=Sat, 28-Sep-2013 00:49:37 GMT;

path=/; domain=.wikipedia.org; httponly

Logout (specific wiki):

Set-Cookie: frwikiforceHTTPS=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT;

path=/; secure; httponly

I originally reported this bug on bug 53379 but this one was focused on a user interaction issue rather than on a real forceHTTPS cookie issue (it was a single wiki); my first remarks are there. I mistakenly made a diagnosis and proposed a solution, but the real bug is this one.


Version: master
Severity: major

Details

Reference
bz53536

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 2:02 AM
bzimport set Reference to bz53536.

I'm pretty sure this is at least major, not "normal". Is somebody working on this?

This is a bug in Extension:CentralAuth. It fails to clear the cookie when CentralAuthUser::deleteGlobalCookies() is called.

@Bartosz: yes, major.

I added a temporary work-around in [[meta:HTTPS]] instructing the users to remove the cookies forceHTTPS, although the cookies are quite hidden in most browsers and difficult to find for the users.

(In reply to comment #2)

This is a bug in Extension:CentralAuth. It fails to clear the cookie when
CentralAuthUser::deleteGlobalCookies() is called.

It's more than that. CentralAuth doesn't actually need to call deleteGlobalCookies() on logout to make the user be logged out everywhere because changing the saved login token means the centralauth_Token cookies are no longer valid. So the calling of deleteGlobalCookies() on all wikis on logout was removed during the course of the SUL2 work. That needs to be re-added in order to clear this forceHTTPS cookie on all wikis.

We're also going to have to take care of the forceHTTPS cookie set by core: Say you log in on dewiki, you actually get *two* forceHTTPS cookies, one for de.wikipedia.org set by core and one for .wikipedia.org set by CentralAuth. If you log out on dewiki everything works fine, but if you log out on any other site then that de.wikipedia.org forceHTTPS cookie isn't (and can't easily be) deleted.

Change 82634 had a related patch set uploaded by Anomie:
Delete forceHTTPS cookies on logout

https://gerrit.wikimedia.org/r/82634

Change 82634 merged by jenkins-bot:
Delete forceHTTPS cookies on logout

https://gerrit.wikimedia.org/r/82634

As per https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap the fix will be available ("deployed") on MediaWiki.org on Thursday September 12, on all non-Wikipedia sites on Monday September 16, and on Wikipedias on Thursday September 19.
Please reopen if the problem still exists after these dates. Thanks!

The "Backport_WMF?" flag is still unresolved here. Is it going to be backported? It should IMO.

(In reply to comment #8)

The "Backport_WMF?" flag is still unresolved here. Is it going to be
backported? It should IMO.

If you think we need it sooner than Sept 19th, then yes, we can update CA to master in one go sometime this week.

Sep 19th is in ten days, and there are users who have trouble editing because of this bug right now. So yes, I'd suggest a quicker deployment.

Sorry for not responding to the backport request sooner. We hope to get this deployed today. The schedule is tight due to it being a short deploy-week here (we have an All Hands on Thurs/Fri, thus making our deploy week only 3 days long instead of the normal 4).

We had a bug in the CentralAuth patch, so I reverted the change, and we'll need to deploy it later this week.