BBlack added a comment. As best I can tell from my own testing (but I think someone with deeper insight into the CORS change for (www|query).wikidata.org and S:UL and such would need to confirm this sounds sane): I was able to reproduce the issue, and I was able to apparently perma-fix it for myself by deleting the centralauth_Token cookie in my browser cookie set that was stored under "wikidata.org" (as opposed to www.wikidata.org).
From the server end, we can't tell what domain a cookie was set for, only that it matched for the browser's request. So we could, for example, put a hack in varnish to delete the centralauth_Token cookie on requests with the exact Host header "wikidata.org" just to kill the one problematic cookie, but users would actually have to visit https://wikidata.org/ to trigger the fix. We could maybe do that part by embedding a request to it in all accesses to wikidata.org temporarily or something like that. There might be some better application-level way of dealing with this, though. TASK DETAIL https://phabricator.wikimedia.org/T109038 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: BBlack Cc: Daniel_Mietchen, BBlack, thiemowmde, Magnus, Akoopal, Ortjens, Krenair, Billinghurst, Mbch331, Aklapper, aude, hoo, Anomie, Lydia_Pintscher, csteipp, Legoktm, Wikidata-bugs, Snowolf, Malyacko _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
