Steps to reproduce:
- Visit zh.wikipedia.org through a globally blocked IP (usually an open proxy)
- Login an account with no autoconfirmed flag
- Ask a local admin to grant IPBE to the account
- 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):
- Refresh the page (follow directions given)
- Preview the changes (forced to do this because the account is not autoconfirmed)
- 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.