Oddly enough, I was able to edit logged out in an incognito window.

https://grafana.wikimedia.org/d/000001590/sessionstore?orgId=1&from=now-1h&to=now

Office wiki is also affected

That's odd: otrs-wiki is affected, but it doesn't use global accounts/centralauth...

Just checked, I can't edit Wikidata or log into QuickStatements.

Seems to be working now.

Solved for fr.wikipedia.

Does appear to be fixed, likely caused by Thursday™

Working for me on en.wikipedia. Issue started at roughly 18:36:49 per recent changes.

I can edit again, but protecting a page was somehow still prohibited (first attempt) but resubmission of the form worked around the issue. (nlwiki)

Still happening (loss of session data error on attempted save) on enwiki as of this time stamp.

For me, it's now 50/50 whether or not my tokens are valid or not across all Wikimedia Wikis. My issues started about 15 mins following the first report.

I had the issue for 10 minutes, seems to be gone by now (English Wikipedia, Wikidata, and authentication here)

Working in es.wikipedia for me.

office wiki still affected

Working also in es.wikivoyage for me.

office wiki working! :) thanks!

On commons csrf token error on loading (not consistent) and login errors on ruwiki

This might be due to the reason that you are trying to login even after you have logged in once. Try refreshing the page and clear cache

@Agusbou2015: Please do not resolve any tasks for no reason. This is up to developers. Thanks a lot.

I was affected on enwiki. I thought it was because of this CSS which I then removed. I thought it was my browser cookies. Turns out, it's the system.

In T255179#6216559, @BPirkle wrote:

https://grafana.wikimedia.org/d/000001590/sessionstore?orgId=1&from=now-1h&to=now

https://grafana.wikimedia.org/d/000001590/sessionstore?orgId=1&from=1591900083237&to=1591903561732

Should something be done about users who thought they have logged out but actually didn't?

In T255179#6218789, @Tgr wrote:

Should something be done about users who thought they have logged out but actually didn't?

I guess this is late so probably no, but how would we be identifying those ? What action would we be taking ? I am guessing forcibly logging them out?

In T255179#6227727, @akosiaris wrote:

I guess this is late so probably no, but how would we be identifying those ? What action would we be taking ? I am guessing forcibly logging them out?

That's what we did for similar issues in the past, yeah. If there's some log (e.g. in Logstash) to find out who attempted logout then based on that, otherwise decide if the impact was severe enough to log everyone out.

As an external observer, I'm fearful of "log everyone out". This will cause a spike in traffic to the authentication infrastructure as everybody logs back in again. Which, of course, was the root cause of this problem to begin with. Is there some way to do a rolling logout, killing say, 1% of the sessions per hour?

In T255179#6228151 RoySmith wrote

log everyone out

Why should this actually be done? I think only those who face issues now, requires this to be done I think. Also, since nobody has recently mentioned here that they face issues, I think by the message posted by akosiaris regarding insufficient capacity, I think the problem stands resolved.

In T255179#6228151, @Adithyak1997 wrote:

Why should this actually be done?

To protect the integrity and avoid exposing the personal data of users who have used Wikimedia sites on public computers or on someone else's computer and thought they logged out but actually didn't.

In T255179#6228123, @RoySmith wrote:

As an external observer, I'm fearful of "log everyone out". This will cause a spike in traffic to the authentication infrastructure as everybody logs back in again. Which, of course, was the root cause of this problem to begin with. Is there some way to do a rolling logout, killing say, 1% of the sessions per hour?

We have added sufficient capacity to the sessionstore infrastructure, so I am not afraid of that event repeating in this manner even if we logged everyone out. The nuisance caused to all users (including all those that were not active during the incident) however is something I am worried about, so I 'd prefer if we did not do a global logout.

I was approached by two users of ukwiki this week about persisting "invalid CSRF token" error.
Could it be that the issue, described in this task, continues to happen?

In T255179#6314620, @Ata wrote:

Could it be that the issue, described in this task, continues to happen?

No. See T258121: Logging in to a wiki sometimes fails with 'sessionfailure' error (coinciding with SameSite rollout) for the ongoing issue.