Page MenuHomePhabricator

CentralAuth deletes session cookies when gadgets make requests to another wiki on IPBE account, causing session loss
Open, Needs TriagePublic

Description

2022-06-15 Updates about Android App
You need to set English in app setting "Wikipedia languages"

photo_2022-06-15_18-23-07.jpg (407×606 px, 22 KB)

Login and wait a second. There is a http request with the following headers:

HTTP GET https://en.wikipedia.org/w/api.php?format=json&formatversion=2&errorformat=html&errorsuselocal=1&action=query&meta=tokens&type=login
Response header:
set-cookie: ss0-enwikiSession=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly
set-cookie: enwikiSession=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: ss0-centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: ss0-enwikiSession=SECRET1; path=/; secure; HttpOnly
set-cookie: enwikiSession=SECRET1; path=/; secure; HttpOnly; SameSite=None

2021-12-29 Updates
This problem seems to affect Android App users too. When they log in via a VPN, they get automatically logged out moments after they login. Experiments shows that forcefully creating an English Wikipedia account solves the problem.

2021-11-11 Updates
Thanks for @MilkyDefer's comment in T244635#7498372

Steps to reproduce: (IPBE is optional to confirm login status. You can confirm it in the other way.)

  1. Make sure your account doesn't have a local account in en.wikipedia.org (Check it in https://meta.wikimedia.org/wiki/Special:CentralAuth)
  2. (Optional) Make sure your account have ipblock-exempt permission in zh.wikipedia.org
  3. Visit wikis through a globally blocked IP (Make sure you cannot create accounts in https://en.wikipedia.org/wiki/Special:CreateAccount)
  4. (Optional) Visit https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E6%B2%99%E7%9B%92&action=edit&safemode=1
  5. (Optional) You should able to edit this page because you have ipblock-exempt permission in zh.wikipedia.org.
  6. Run following JavaScript in your browser console (You can load any js in en.wikipedia.org)
mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Xiplus/emptyscript.js&action=raw&ctype=text/javascript&t=' + Date.now())
  1. Check the request information in browser dev tools. Check the Response Headers. You can see
set-cookie: ss0-enwikiSession=SECRET1; path=/; secure; HttpOnly
set-cookie: enwikiSession=SECRET1; path=/; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-User=YOURUSERNAME; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_User=YOURUSERNAME; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-Token=SECRET2; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Token=SECRET2; expires=Fri, 11-Nov-2022 12:13:44 GMT; Max-Age=31536000; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: ss0-centralauth_Session=SECRET3; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Session=SECRET3; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
  1. Run the script in step 6 again
  2. Check the Response Headers again. You can see
set-cookie: ss0-enwikiSession=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly
set-cookie: enwikiSession=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_User=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: centralauth_ss0-Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
set-cookie: ss0-centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly
set-cookie: centralauth_Session=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; domain=.wikipedia.org; secure; HttpOnly; SameSite=None
  1. Your cookies are deleted. Then reload the page.
  2. You are logged out. (Optional) You can't edit the page because your IP is blocked.
  3. Wait a second. Then you can see "Central login" notification (You are centrally logged in as XXX. Reload the page to apply your user settings.).
  4. Reload the page. (Optional) You can edit the page now because you are logged in.

Original task description:

Steps to reproduce:

  1. Visit zh.wikipedia.org through a globally blocked IP (usually an open proxy)
  2. Login an account with no autoconfirmed flag
  3. Ask a local admin to grant IPBE to the account
  4. Click the "edit" button on a page

Expected: Edit box and tools appears normally.

Actual: A hint appears on the upper right corner, saying:

Central login
You are centrally logged in as <username>. Reload the page to apply your user settings.

Meanwhile, username on the upper right corner is replaced by Not logged in. Since we are using a globally blocked IP, the block interface also appears. (Screeshot on zhwiki)

Steps to reproduce (continue):

  1. Refresh the page (follow directions given)
  2. Preview the changes (forced to do this because the account is not autoconfirmed)
  3. Publish the changes

Expected: Return to read mode and see the changed things.

Actual: What happened before occurred again. We lose login session once we click the "Save" button and return to edit mode after refreshing the page. The changes we made will never be published (because the IP is blocked, it is impossible to save them without login).


Before reporting this problem here, I tried granting confirmed flag to affected users. They successfully saved their changes after getting confirmed permission. However, some of our abusefilters and other anti-vandalism stuffs rely on confirmed flags so that we are not expected to grant it simply for avoiding this technical problem.

Some affected users also reported successful edits after changing to those IPs which are not globally blocked. Therefore, I guess it is using globally blocked IP and having no confirmed flag that lead to login session losing.

I yet don't know whether there's a chance to meet this issue or it always happen (if you follow the step mentioned above). At least users who were granted confirmed flag saw no problem in saving changes.


Sysops and experienced users on zhwiki received report of this issue from both mobile and desktop version, as well as various browsers and operating systems (If my memory is correct). We also asked the affected users to check their cookie settings and find no problem there. Though I have only seen reports from zhwiki, I believe that this is a general MediaWiki problem.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Hi, I'm a new wiki user and can reproduce this issue. What can I help to resolve this?

@Urbanecm It might be a bit late to tell, but earlier this year, the local community have noticed that if the users who run into the problem submit their edits before the 2010 version of the wikitext editor load completely, the submission would be succeeded and their sessions would not lose in a few days. That might be a clue about why it happens.

What I mean is that there might be some problems with the scripts (or something) which will be loaded in the very end of the editing page loading procedure, and if the script is not loaded, and the user successfully submitted their edit, the local cookie would stop the problem from occuring for some time.

I could reproduce the issue when I was a New user in Dec.2020.
Now,There are also many users to say they have the problem in groups.

Use non-globally blocked IP or confirmed right to edit also reproduced.

According to T295010, This will not log out if you are editing in debug mode.

By using controlled expriments, I am highly confident that this is caused by RefToolbar, which is enabled by default for everyone. Disabling this gadget from user preferences solves this problem, and once enabling it, I lose my login status.

I really have no clue why this script could manipulate my cookies, since I see nothing related to it in its code.

Looks like this is a CentralAuth problem: I could not create an English Wikipedia local account via CentralAuth thanks to English Wikipedia's local blocking of the web host. Thus, sending a request to a site without a local account (nor create one) somehow causes the CentralAuth-related cookies be deleted by response header. After the CentralAuth cookies got deleted, another request is sent to Chinese Wikipedia locally (due to a script loading) - without CentralAuth cookies - now Chinese Wikipedia's local login cookies are deleted too. The user is now technically "auto logged out".

I somehow auto created an English Wikipedia local account, and the problem would not happen, even if I am behind a blocked address.

This is a complex logic problem, and I am adding the CentralAuth team here.

Thanks for @MilkyDefer's comment. I can reproduce the bug every times. I have provided a stable steps to reproduce it in task description.

I am pinging @Urbanecm here to see if it is possible to pinpoint the exact problem with the code with our newest discoveries. Should I change the title?

I think we can either:

  • Prevent the change of cookies related with centralauth; or
  • Allow auto creation of a local account from centralauth, even if the IP address is blocked.

Mentioned in SAL (#wikimedia-operations) [2021-11-15T16:34:41Z] <urbanecm> [urbanecm@mwmaint1002 ~]$ mwscript extensions/CentralAuth/maintenance/createLocalAccount.php --wiki=enwiki 'MU test T244635 1'

I confirm the observations – https://en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbar.js&action=raw&ctype=text/javascript gets loaded for my fresh zh.wikipedia account (with local IPBE), and it removes my session in its entirety. Nice found!

After I forcefully created the acc at enwiki, everything suddenly starts to work.

Apart from the potential solutions you offered, simply copying RefToolbar's code to zhwiki space should workaround the issue. A simple IA-privileged bot should be able to maintain the page if so desired. Not ideal, but better than status quo I think?

I am pinging @Urbanecm here to see if it is possible to pinpoint the exact problem with the code with our newest discoveries. Should I change the title?

Yes please :). Now it's finally clear what's happening. Not yet why, but we can iterate from here.

I think we can either:

  • Prevent the change of cookies related with centralauth; or

Definitely worth investigation! @Majavah, do you have an idea if this happens within CA or core?

  • Allow auto creation of a local account from centralauth, even if the IP address is blocked.

That's intentional, otherwise local account creation blocks would be useless (you would be able to just bypass via other projects).

  • Prevent the change of cookies related with centralauth; or

Definitely worth investigation! @Majavah, do you have an idea if this happens within CA or core?

I think this is happening in CentralAuthSessionProvider, this code block is currently my best guess.

在T244635#7504225中,@Urbanecm写道:

Apart from the potential solutions you offered, simply copying RefToolbar's code to zhwiki space should workaround the issue. A simple IA-privileged bot should be able to maintain the page if so desired. Not ideal, but better than status quo I think?

Now only the cross-domain request for RefToolbar gadget has been found to cause this problem, but there are multiple scripts in zhwiki that have cross-domain requests. I’m not sure if there are other scripts that can cause this problem?

在T244635#7504225中,@Urbanecm写道:

Apart from the potential solutions you offered, simply copying RefToolbar's code to zhwiki space should workaround the issue. A simple IA-privileged bot should be able to maintain the page if so desired. Not ideal, but better than status quo I think?

Now only the cross-domain request for RefToolbar gadget has been found to cause this problem, but there are multiple scripts in zhwiki that have cross-domain requests. I’m not sure if there are other scripts that can cause this problem?

Yes, very likely requesting the same gadget from ie. cswiki would have the same implication (your computer making a request to cs.wikipedia, which doesn't let you to autocreate an acc., which logs you out).

Diskdance renamed this task from New users losing login session when editing from a globally blocked IP to CentralAuth deletes session cookies when gadgets make requests to another wiki on IPBE account, causing session loss.Nov 27 2021, 3:48 PM
Diskdance updated the task description. (Show Details)
在T244635#7504225中,@Urbanecm写道:

Apart from the potential solutions you offered, simply copying RefToolbar's code to zhwiki space should workaround the issue. A simple IA-privileged bot should be able to maintain the page if so desired. Not ideal, but better than status quo I think?

Now only the cross-domain request for RefToolbar gadget has been found to cause this problem, but there are multiple scripts in zhwiki that have cross-domain requests. I’m not sure if there are other scripts that can cause this problem?

Yes, very likely requesting the same gadget from ie. cswiki would have the same implication (your computer making a request to cs.wikipedia, which doesn't let you to autocreate an acc., which logs you out).

But why should it remove the entire session even on other wiki rather than just disallow the autocreation of a local account? Don't think it's appropriate.

There are some reports claiming that they encountered an auto-logout problem from their Android app. From the video they showed us, they got logged out seconds after they logged in. And we later checked one of them's CentralAuth and found that he didn't have English Wikipedia local account attached. I am wondering whether this could be related.

There are some reports claiming that they encountered an auto-logout problem from their Android app. From the video they showed us, they got logged out seconds after they logged in. And we later checked one of them's CentralAuth and found that he didn't have English Wikipedia local account attached. I am wondering whether this could be related.

I don't think so. To trigger this bug, you need to load resource from a different wiki (like a script, gadget or use script). AFAIK, the android app uses API for making the edits, so there's no web-based session at all. Or am I missing something?

@Urbanecm We have a new user experiencing the Android App problem. User:Evesiesta reports that he immediately gets logged out whenever he successfully logs in. Could you create a local English Wikipedia account for him and we could see whether this will solve his problem?

@Urbanecm We have a new user experiencing the Android App problem. User:Evesiesta reports that he immediately gets logged out whenever he successfully logs in. Could you create a local English Wikipedia account for him and we could see whether this will solve his problem?

Done. Let's see what happens.

It's midnight in his time zone and I am afraid that we need to wait for tomorrow. I will update this message as soon as I receive his feedback.

Update:
@Urbanecm "Problem solved", he said. I am now very confident that this should be the exact cause of Android App auto-logout issue. Bring the Android team in?

This is interesting. I'm curious which resources from the English Wikipedia are loaded by the Android app. Definitely yes, let's bring the Android team people too.

@Urbanecm Thanks for the heads up. Would someone mind restating the exact steps to reproduce this from the Android app?

User:YQXP123 reproduced the bug without IPBE and also not using proxy.

After this user closed the Refbar tool,the problem seems resolved. This user does not have a local account in enwiki...

According to T305025, automatically confirm that the user will be automatically logged out when accessing ruwiki.

@Urbanecm Thanks for the heads up. Would someone mind restating the exact steps to reproduce this from the Android app?

This is test at 00:38, 24 May 2022.

  1. Register an account on zhwiki and request temporary ipblock-exempt. (don't login it, or gadgets may let you auto create enwiki's account.)
  2. Open a VPN on Android. In this test, I use ProtonVPN free node.
  3. Login to Wikipedia App, after about five to ten seconds you will get a warning that you are logged out.

After the test, I got a commons account (see https://meta.wikimedia.org/wiki/Special:CentralAuth/RainBeforeSun).

image.png (341×1 px, 41 KB)

I also have this problem in plwiki. Steps to reproduce.

  1. ip bloked on enwiki, but not blocked on plwiki
  2. create new account on plwiki
  3. try to edit any article and add a link (this is needed to be asked of CAPTCHA, only then session cookies will be lost)
  4. enter correct CAPTCHA
  5. click submit

Then somehow a request is sent to en.wikipedia.org where ip is blocked and a local account can not be autocreated. Then session cookies are removed.

@WMDE-leszek maybe you can have a look? Or redirect to someone who can solve this. It is also particularly annoying that at the moment a new user cannot even add link to any article in plwiki (if ip is blocked on enwiki)

@WMDE-leszek I am not really on top of this, WMDE does not maintain the related code, so I cannot be of much help, apologies.
However, I see @Urbanecm_WMF was quite active here in his non-WMF identity, maybe they could help identifying who (which WMF team etc) could help here?

No WMF team owns CentralAuth itself, in practice most recent maintenance has been done by @Zabe and myself. ConfirmEdit making cross-wiki requests sounds like a separate bug in itself, and that extension is owned by Editing-team.

[...]
However, I see Urbanecm_WMF was quite active here in his non-WMF identity, maybe they could help identifying who (which WMF team etc) could help here?

Unfortunately, can't help here much either. As Majavah said, there is no WMF team assigned to maintain CentralAuth, even though it's a critical extension in our setup. Code stewardship request is pending as T252244: CentralAuth extension: Code stewardship review.

Then somehow a request is sent to en.wikipedia.org

It would be useful to track down what kind of request is made, otherwise it's hard to tell where to start looking.

If you manage to find simpler steps to reproduce, that would also help the debugging efforts.

This is interesting. I'm curious which resources from the English Wikipedia are loaded by the Android app. Definitely yes, let's bring the Android team people too.

The app try to login on enwiki. See 2022-06-15 Updates in Description.
If you exclude English in "Wikipedia languages" settings, no requests will be sent to en.wikipedia.org. You won't be logged out.

In https://gerrit.wikimedia.org/g/mediawiki/core/+/514d941a73f90f56bc0e45fa3c755d3d3c9c5d36/includes/session/SessionManager.php#719

$metadata = {"provider":"CentralAuthSessionProvider","providerMetadata":{"CentralAuthSource":"CentralAuth"},"userId":0,"userName":null,"userToken":null,"remember":false,"forceHTTPS":false,"expires":1655393527,"loggedOut":0,"persisted":true}

Then run into Line 756
Log shows

Session "[50]CentralAuthSessionProvider<+:0:Test2>nt31sicb3fqaem4rt6j7irq1ii353tbs": Metadata has an anonymous user, but a non-anon user was provided
and
(string)$userInfo = <+:0:Test2>  // (Test2 is the account username)

Then return FALSE back to https://gerrit.wikimedia.org/g/mediawiki/core/+/514d941a73f90f56bc0e45fa3c755d3d3c9c5d36/includes/session/SessionManager.php#546
So jump into Line 565, then delete the cookies.

When I tested this locally using GlobalBlocking, I found that auto-creation actually succeeds. The IP address is globally blocked, but that is not actually checked for in CheckBlocksSecondaryAuthenticationProvider. There's a comment which says it is the responsibility of authorizeCreateAccount(), but that is not called.

That's surprising to me since I assumed this bug was about local account creation being blocked. In T244635#7504225 @Urbanecm said that it's not possible to allow local creation, but maybe it's already allowed?

In step 7 of the task description, you can see Set-Cookie headers for centralauth_User together with enwikiSession in the same request. These are cookies from CentralAuthSessionProvider::persistSession(). It's hard to see how that could happen without a successful login to enwiki.

Confirmed still happended when es.wikipedia.org block My IP range (VPS IP).
Some gadgets' JavaScript on zh.wikipedia.org load resource from es.wikipedia.org, make me suddenly logout.