Discussed with @Dreamy_Jazz, we think this is something for MediaWiki-Platform-Team to take on as part of the SUL3 work, but we would be happy to review the patch(es).

What happens is that testwiki sends you to auth.wikimedia.org to be used as a remote identity provider, but then internally auth.wikimedia.org is also testwiki. So you do a normal login there, the auth.wikimedia.org session gets written, and then get sent back to the normal testwiki domain, where another login happens, and the local session gets written.

In theory the second login is the "weird" one (e.g. if you are signing up instead of logging in, the first action will be a signup but the second a login) so that's the one that should be suppressed. It's a bit of a hack but we can probably send a "was this a remote login" flag in the extraData array of AuthManagerLoginAuthenticateAudit - not sure what's a reasonable abstraction there, though. Would it make sense to generally not send LoginNotify emails / not log CheckUser data for remote identity provider logins (think something like a "log in with Facebook" button)? Probably not, and I'd rather not add a completely SUL3-specific check to CheckUser/LoginNotify. Not sure I see a better option, though.

The first entry has a limited amount of Client Hints data (only low entropy) and was logged under an IPv4 address
The second entry had the full Client Hints data (i.e. high entropy) and was logged under an IPv6 address

No idea what's up with that. How is this data collected? And why would the IP differ, even if requesting high entropy fails for some reason?

In T385572#10523361, @Tgr wrote:

How is this data collected?

For a successful login attempt this is collected via HTTP headers. For failed login attempts this is collected via JS code which sends the data to a REST API.

And why would the IP differ

I've no idea either, but maybe because one site accepts IPv6 over IPv4? The IP is taken from the main request context when calling the hook, so the code doing this is not in CheckUser.

Change #1118249 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Suppress login audit hook in local leg of SUL3 authentication

https://gerrit.wikimedia.org/r/1118249

Regarding the IPv6 vs IPv4 addresses, @Dreamy_Jazz can you look at the output of these API requests, and say whether they respond with an IPv6 or IPv4 address?

• https://en.wikipedia.org/w/api.php?action=query&meta=globaluserinfo
• https://auth.wikimedia.org/enwiki/w/api.php?action=query&meta=globaluserinfo

For me, they both report my IPv6 address. If that's not the case for everyone, I think that would be a question for SRE whether that's normal or a bug.

In T385572#10534366, @matmarex wrote:

Regarding the IPv6 vs IPv4 addresses, @Dreamy_Jazz can you look at the output of these API requests, and say whether they respond with an IPv6 or IPv4 address?

• https://en.wikipedia.org/w/api.php?action=query&meta=globaluserinfo
• https://auth.wikimedia.org/enwiki/w/api.php?action=query&meta=globaluserinfo

For me, they both report my IPv6 address. If that's not the case for everyone, I think that would be a question for SRE whether that's normal or a bug.

I see IPv6 addresses when visiting those URLs.

In T385572#10534366, @matmarex wrote:

Regarding the IPv6 vs IPv4 addresses, @Dreamy_Jazz can you look at the output of these API requests, and say whether they respond with an IPv6 or IPv4 address?

• https://en.wikipedia.org/w/api.php?action=query&meta=globaluserinfo
• https://auth.wikimedia.org/enwiki/w/api.php?action=query&meta=globaluserinfo

For me, they both report my IPv6 address. If that's not the case for everyone, I think that would be a question for SRE whether that's normal or a bug.

Both links produce IPv6 addresses for me. This is the same for a request to test.wikipedia.org.

Change #1118249 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Suppress login audit hook in local leg of SUL3 authentication

https://gerrit.wikimedia.org/r/1118249

Change #1119874 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.16] Suppress login audit hook in local leg of SUL3 authentication

https://gerrit.wikimedia.org/r/1119874

Change #1119874 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.16] Suppress login audit hook in local leg of SUL3 authentication

https://gerrit.wikimedia.org/r/1119874

Mentioned in SAL (#wikimedia-operations) [2025-02-17T14:21:19Z] <tgr@deploy2002> Started scap sync-world: Backport for [[gerrit:1119874|Suppress login audit hook in local leg of SUL3 authentication (T385574 T385572)]]

Mentioned in SAL (#wikimedia-operations) [2025-02-17T14:26:30Z] <tgr@deploy2002> tgr: Backport for [[gerrit:1119874|Suppress login audit hook in local leg of SUL3 authentication (T385574 T385572)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-02-17T14:49:02Z] <tgr@deploy2002> Finished scap sync-world: Backport for [[gerrit:1119874|Suppress login audit hook in local leg of SUL3 authentication (T385574 T385572)]] (duration: 27m 43s)

I tested both SUL2 and SUL3 login and saw the same (IPv6) IP and the same amount of client hints (high-entropy, I think? it included the exact browser version). And only once per login, now that the patch is deployed.