Also see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems

Seconding what @Aklapper posted.

For example, I log in to the English Wikipedia. If I go to the Italian Wikipedia, I'm still logged in. But if I go to mediawiki.org, I have to log in again. And when I go to wikidata.org, I have to log in yet again. I'm not sure what is the logic here and how are the sites grouped, but it definitely happens again and again.

That description makes it sound like it's grouped by second-level domain name. If you visit en.wiktionary.org do you have to log in, but then after that can you visit any other site at wiktionary.org without re-logging-in? And so on for other domains?

Note wikimedia.org may be an exception, cookies are set differently there since that domain has other sites on it too. So having to re-log-in at both Meta and Commons might be expected.

Also something to check is whether your Firefox has the feature mentioned in T202028: CentralAuth fails when using "site isolation" in Google Chrome and Chromium or "first-party isolation" in Firefox enabled.

In T203264#4549152, @Aklapper wrote:

Also see and follow https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems

Thanks. I've tried everything there and nothing helped. Here are HAR files from my log in attempts: I am logged in in en.wikipedia.org, but not in wikidata.org

In T203264#4549207, @Anomie wrote:

Seconding what @Aklapper posted.

For example, I log in to the English Wikipedia. If I go to the Italian Wikipedia, I'm still logged in. But if I go to mediawiki.org, I have to log in again. And when I go to wikidata.org, I have to log in yet again. I'm not sure what is the logic here and how are the sites grouped, but it definitely happens again and again.

That description makes it sound like it's grouped by second-level domain name. If you visit en.wiktionary.org do you have to log in, but then after that can you visit any other site at wiktionary.org without re-logging-in? And so on for other domains?

Yes, looks like it. If I log in to en.wiktionary.org, I am auto-logged-in to eo.wiktionary.org.

Also something to check is whether your Firefox has the feature mentioned in T202028: CentralAuth fails when using "site isolation" in Google Chrome and Chromium or "first-party isolation" in Firefox enabled.

I have the defaults there:

• privacy.firstparty.isolate is false
• privacy.firstparty.isolate.restrict_opener_access is true

In T203264#4550674, @Amire80 wrote:

Here are HAR files from my log in attempts: I am logged in in en.wikipedia.org, but not in wikidata.org

Unfortunately neither of these shows login attempts. What we need to see is the load of Special:UserLogin, then the submission of that form and the subsequent page loads until the login process is finished and all the images load on the destination page, and then the load of the page that shows not being logged in. You might also visit Special:UserLogin on the second wiki to force it to attempt to auto-login.

You're welcome to create a throwaway account and change its password immediately after generating the HAR file, and/or to edit the HAR file to obscure the password.

In case you're curious, what I'll be looking for is to see that the browser is making the expected accesses to get the Set-Cookie headers and then that those headers are being sent back by the browser on subsequent requests and seeming to be recognized properly based on the server's responses.

Archive 18-09-01 15-46-51.har1 MBDownload

This seems to show accessing https://www.wikidata.org/, getting redirected to https://www.wikidata.org/wiki/Wikidata:Main_Page, and then loading that page while not being logged in. I can see that the browser is not sending any CentralAuth cookies in any of the requests, but there's no way to tell whether anything ever tried to set them. It also seems that the "CentralAuthAnon" local storage key must have been set, since it doesn't seem to have attempted to hit Special:CentralAutoLogin.

Archive 18-09-01 15-46-31.har1 MBDownload

This seems to show accessing https://en.wikipedia.org/, getting redirected to https://en.wikipedia.org/wiki/Main_Page, and then loading that page while logged in. I can see that the browser is sending proper CentralAuth cookies and the responses seem consistent with being logged in.

In T203264#4550674, @Amire80 wrote:

In T203264#4549152, @Aklapper wrote:

Also something to check is whether your Firefox has the feature mentioned in T202028: CentralAuth fails when using "site isolation" in Google Chrome and Chromium or "first-party isolation" in Firefox enabled.

I have the defaults there:

• privacy.firstparty.isolate is false
• privacy.firstparty.isolate.restrict_opener_access is true

Thanks for checking that. One other thing I just thought of is to check whether you have an ad blocker or other privacy browser extension that might be blocking the 1x1 pixel images that we currently use to attempt to set the cross-wiki cookies. If it has logs you might see if they mention blocking URLs that include "Special:CentralAutoLogin".