Change Details

**Wiki(s) affected:** `wikiweewiki` (for now; to be added as discovered and confirmed) **Issue:** [[ https://wikiwee.miraheze.org/wiki/Special:Contributions/148.74.235.89 | This global block ]], despite being not only a block of anonymous users but logged in users as well, has **no effect** on the LTA's ability to edit on the wiki today. For greater clarity, this LTA is the same LTA that discovered a bug with the #createwiki extension and was able to overwrite certain data in certain wiki request columns until the bug was patched I had a Wikimedia Steward (AmandaNP) and @Agent_Isai check the Special:ListGroupRights and Special:Version special pages with me to see if I missed anything glaringly obvious. `ipblock-exempt` is not assigned to `*` nor was that IP address locally whitelisted, so doesn't appear to be the case. This Miraheze LTA is also globally blocked on the Wikimedia network of wikis as crosswiki abuse. In addition, I also double-checked via the CheckUser extension on that wiki to see if the XFF header information was //different// than the blocked IP. It was not. It would not surprise me and @Agent_Isai in the least if the LTA has discovered a new bug with the [[ https://www.mediawiki.org/wiki/Extension:GlobalBlocking#Configuration | GlobalBlocking ]] extension, but I wanted to check with the MediaWiki SRE team to confirm there are no configuration issues with Miraheze's configuration: # Is `$wgApplyGlobalBlocks` set to `true`, correctly, on //all// Miraheze wikis except for `metawiki`? # Is `$wgGlobalBlockingBlockXFF` set to `true` or `false`? If the //latter//, as a Steward, I would certainly endorse setting this to `true` # Does every wiki have a `globalblocking` SQL table or have we specified a different SQL table via `$wgGlobalBlockingDatabase` and have all database users been given the following permissions, `SELECT, UPDATE, INSERT, DELETE`, at //minimum//? # Are there any other identifiable configuration errors? If no issues with the above points, are there any other known or unknown extension conflicts that could be giving us grief and causing an issue? My initial thought focused on [[ https://www.mediawiki.org/wiki/Extension:NewSignupPage | this extension ]]. No particular reason, other than I'd not seen it and noticed that Bukkit (no need to add him to this task, please) had granted the `bypasstoscheck` user right to the `founder` group but mainly because of the extension's interactions with **Special:CreateAccount**. A thorough and rigorous extension conflict check should be done, if possible. Finally, if //still// nothing, can you provide additional details useful for raising a GlobalBlocking bug report to Wikimedia? Thanks so much! :)

**Wiki(s) affected:** `wikiweewiki` (for now; to be added as discovered and confirmed) **Issue:** [[ https://wikiwee.miraheze.org/wiki/Special:Contributions/148.74.235.89 | This global block ]], despite being not only a block of anonymous users but logged in users as well, has **no effect** on the LTA's ability to edit on the wiki today. For greater clarity, this LTA is the same LTA that discovered a bug with the #createwiki extension and was able to overwrite certain data in certain wiki request columns until the bug was patched (T9018) I had a Wikimedia Steward (AmandaNP) and @Agent_Isai check the Special:ListGroupRights and Special:Version special pages with me to see if I missed anything glaringly obvious. `ipblock-exempt` is not assigned to `*` nor was that IP address locally whitelisted, so doesn't appear to be the case. This Miraheze LTA is also globally blocked on the Wikimedia network of wikis as crosswiki abuse. In addition, I also double-checked via the CheckUser extension on that wiki to see if the XFF header information was //different// than the blocked IP. It was not. It would not surprise me and @Agent_Isai in the least if the LTA has discovered a new bug with the [[ https://www.mediawiki.org/wiki/Extension:GlobalBlocking#Configuration | GlobalBlocking ]] extension, but I wanted to check with the MediaWiki SRE team to confirm there are no configuration issues with Miraheze's configuration: # Is `$wgApplyGlobalBlocks` set to `true`, correctly, on //all// Miraheze wikis except for `metawiki`? # Is `$wgGlobalBlockingBlockXFF` set to `true` or `false`? If the //latter//, as a Steward, I would certainly endorse setting this to `true` # Does every wiki have a `globalblocking` SQL table or have we specified a different SQL table via `$wgGlobalBlockingDatabase` and have all database users been given the following permissions, `SELECT, UPDATE, INSERT, DELETE`, at //minimum//? # Are there any other identifiable configuration errors? If no issues with the above points, are there any other known or unknown extension conflicts that could be giving us grief and causing an issue? My initial thought focused on [[ https://www.mediawiki.org/wiki/Extension:NewSignupPage | this extension ]]. No particular reason, other than I'd not seen it and noticed that Bukkit (no need to add him to this task, please) had granted the `bypasstoscheck` user right to the `founder` group but mainly because of the extension's interactions with **Special:CreateAccount**. A thorough and rigorous extension conflict check should be done, if possible. Finally, if //still// nothing, can you provide additional details useful for raising a GlobalBlocking bug report to Wikimedia? Thanks so much! :)

**Wiki(s) affected:** `wikiweewiki` (for now; to be added as discovered and confirmed) **Issue:** [[ https://wikiwee.miraheze.org/wiki/Special:Contributions/148.74.235.89 | This global block ]], despite being not only a block of anonymous users but logged in users as well, has **no effect** on the LTA's ability to edit on the wiki today. For greater clarity, this LTA is the same LTA that discovered a bug with the #createwiki extension and was able to overwrite certain data in certain wiki request columns until the bug was patched (T9018) I had a Wikimedia Steward (AmandaNP) and @Agent_Isai check the Special:ListGroupRights and Special:Version special pages with me to see if I missed anything glaringly obvious. `ipblock-exempt` is not assigned to `*` nor was that IP address locally whitelisted, so doesn't appear to be the case. This Miraheze LTA is also globally blocked on the Wikimedia network of wikis as crosswiki abuse. In addition, I also double-checked via the CheckUser extension on that wiki to see if the XFF header information was //different// than the blocked IP. It was not. It would not surprise me and @Agent_Isai in the least if the LTA has discovered a new bug with the [[ https://www.mediawiki.org/wiki/Extension:GlobalBlocking#Configuration | GlobalBlocking ]] extension, but I wanted to check with the MediaWiki SRE team to confirm there are no configuration issues with Miraheze's configuration: # Is `$wgApplyGlobalBlocks` set to `true`, correctly, on //all// Miraheze wikis except for `metawiki`? # Is `$wgGlobalBlockingBlockXFF` set to `true` or `false`? If the //latter//, as a Steward, I would certainly endorse setting this to `true` # Does every wiki have a `globalblocking` SQL table or have we specified a different SQL table via `$wgGlobalBlockingDatabase` and have all database users been given the following permissions, `SELECT, UPDATE, INSERT, DELETE`, at //minimum//? # Are there any other identifiable configuration errors? If no issues with the above points, are there any other known or unknown extension conflicts that could be giving us grief and causing an issue? My initial thought focused on [[ https://www.mediawiki.org/wiki/Extension:NewSignupPage | this extension ]]. No particular reason, other than I'd not seen it and noticed that Bukkit (no need to add him to this task, please) had granted the `bypasstoscheck` user right to the `founder` group but mainly because of the extension's interactions with **Special:CreateAccount**. A thorough and rigorous extension conflict check should be done, if possible. Finally, if //still// nothing, can you provide additional details useful for raising a GlobalBlocking bug report to Wikimedia? Thanks so much! :)