aboutsummaryrefslogtreecommitdiffstats
path: root/includes/block
Commit message (Collapse)AuthorAgeFilesLines
* Merge "block: Fix DBS::acquireTarget() race using GET_LOCK()"jenkins-bot2025-04-071-0/+13
|\
| * block: Fix DBS::acquireTarget() race using GET_LOCK()Tim Starling2025-04-071-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A crude solution for the acquireTarget() race condition. Use SQL GET_LOCK() to lock the target from the acquireTarget() call until the transaction is committed. Add FOR UPDATE to the acquireTarget() SELECT, otherwise it just sees the snapshot version of the row and inserts a new row anyway. Add a test which reliably failed prior to the change. Reword the ipb-block-not-found message. This is normal for simultaneous blocks of the same target. Don't contact us. In the API, remap it to "alreadyblocked". Bug: T389028 Change-Id: I1fa35bf08d456a93930194786f77df389217ba61
* | multiblocks: Prevent reuse of loop variableMatěj Suchánek2025-04-051-2/+3
|/ | | | | | | | | | | | | | | | | Why: - BlockIpComplete informs subscribers when a block is placed or updated. - With CONFLICT_NEW, a block can be just inserted, never updated. However, the loop over prior blocks can set $priorBlock to an arbitrary block or keep it null, possibly confusing subscribers of the hook (e.g., by claiming a block is not active anymore). What: - Make sure $priorBlock is always null in this code path. - Also reuse the $priorBlocks array in the loop. Change-Id: I7e6b55a50cb78f77dedc074689dc3fe3b3484a2f
* Merge "Use type declaration on undocumented private functions"jenkins-bot2025-04-021-1/+1
|\
| * Use type declaration on undocumented private functionsUmherirrender2025-04-021-1/+1
| | | | | | | | Change-Id: I0d8d2237500ed6f18439410c902d47c42e4119bc
* | Merge "block: Add autoblock filtering parameters"jenkins-bot2025-04-023-22/+46
|\ \ | |/ |/|
| * block: Add autoblock filtering parametersTim Starling2025-03-213-22/+46
| | | | | | | | | | | | | | | | Add $auto parameter to DatabaseBlockStore::newFromTarget and ::newListFromTarget, to help callers filter autoblocks from result lists. Change-Id: Iad92d205517eb50ab0ce5e8caae58ee761fe19d5
* | Namespace all remaining files in includes/changetagsJames D. Forrester2025-03-252-2/+2
|/ | | | | Bug: T353458 Change-Id: I3cf44dfe5425f2efb8409c83571c427447b053af
* block: Don't modify an autoblock when the user specifies an IPTim Starling2025-03-201-0/+4
| | | | | Bug: T389452 Change-Id: Id7a3f565821231647fe75a24e9ef7efeeb157c5d
* Namespace all remaining files in includes/loggingJames D. Forrester2025-03-192-2/+2
| | | | | Bug: T353458 Change-Id: Ibe1810f1c71316a9124e1dc6ae405097dafd5267
* DatabaseBlockStore: bring bl_timestamp to current when updating blocksMusikAnimal2025-03-191-0/+3
| | | | | | | | | This is because bl_timestamp is compared against bl_expiry when generating relative timestamps in ApiQueryBlocks and BlockLogFormatter (see Ie88ca47053b). Bug: T389275 Change-Id: I3b1adc7095a317785c7d34694a017c8a802406c8
* block: Suppress exception when reblocking a multi-blocked userTim Starling2025-03-172-1/+15
| | | | | | | | | | | | | | | | | | If multiple blocks exist for a given target but the wiki is in the default/old mode with $wgEnableMultiBlocks=false and $wgUseCodexSpecialBlock=false, attempting to reblock the user causes an exception. A race condition in the database has led to a few such multiblocks existing in production wikis. This issue will soon be resolved by migrating to multiblocks, so that the blocks will be allowed and can be easily manipulated. The same error could occur in the future if $wgEnableMultiBlocks is set to true and then rolled back. So, catch the exception and show a regular error in the form instead. Bug: T388743 Change-Id: I67c6ccc20f3c31ba4a4e5734de1641d626adb7f2
* block: Fix failure to sanitize a range blocked with ApiBlockTim Starling2025-03-121-1/+1
| | | | | Bug: T388097 Change-Id: I89baf1b190cf9adefba9a232f57c957a2345f8e5
* block: DatabaseBlock constructor caller migrationTim Starling2025-03-045-26/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | There's about 100 callers of the DatabaseBlock constructor in core tests, most of them passing an address parameter which needs access to the global service container to parse. Many are passing the constructed object straight to DatabaseBlockStore::insertBlock(). So add insertWithParams() for their convenience, which has some handy shortcut parameters, has service access, and throws on failure. The calling code tends to be shorter than before. For unit tests trying to construct DatabaseBlock objects without a service container, direct construction of BlockTarget subclasses is warranted. Add a default to the $wikiId parameters for their convenience. MockBlockManager had its own 'target' parameter, mixed in with block options, carrying its own special idea of a target, which conflicted with DatabaseBlock's new 'target' parameter. Harmonise the parameters and fix the callers. Bug: T382106 Bug: T385966 Change-Id: I78b45a6003b62962211379c36da5587081f90f00
* Merge "Generate machine-readable block info in BlockErrorFormatter"jenkins-bot2025-02-191-3/+12
|\
| * Generate machine-readable block info in BlockErrorFormatterBartosz Dziewoński2025-02-181-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, BlockErrorFormatter would only generate a human-readable error message for permission errors caused by blocks, and PermissionManager would build a PermissionStatus object out of them. Machine-readable block info was added later: UserAuthority would add a Block object to each one, then finally each API module (via ApiBlockInfoTrait) would generate block info from these Block objects. Now all of this happens in BlockErrorFormatter and PermissionManager. For compatibility with older code, remove the extra information when using the deprecated PermissionManager::getPermissionErrors() method. This is a small hack that can be removed together with that method in the future. The changes seem to make a workaround for T357063 in ApiQueryInfo unnecessary (tests added in c55d33ef11 still pass). Bug: T357063 Change-Id: Id121d51a24fbb1d8210e60bdd54c61b16938dd70
* | block: Add a BlockTarget class hierarchyTim Starling2025-02-1925-492/+1164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Main change: * Add a class hierarchy representing block targets, representing a target and type. * Add BlockTargetFactory, replacing BlockUtils. * Add CrossWikiBlockTargetFactory, replacing BlockUtilsFactory. * Construct a BlockTarget object early in the request flow and pass it down through the layers, instead of having every layer interpret UserIdentity|string target specifications. Also: * Remove Block::TYPE_ID. Nothing uses it in code search, so there's no point in porting it to the new system. * Stop using the type constants as specificity scores. Add BlockTarget::getSpecificity(). * Add DatabaseBlockStore::newUnsaved() to replace direct construction of DatabaseBlock in insertBlock() callers. There are many such callers in tests. This is part of the effort to remove the service container usage in DatabaseBlock::__construct(). * Make DatabaseBlock::getRangeStart() and getRangeEnd() return null if the block is not a range, since that is convenient for their only caller following the resolution of T51504. * Add DatabaseBlock::getIpHex() which similarly maps to a DB field in the new schema. * In ApiBlock and ApiUnblock, have ParamValidator provide UserIdentity objects instead of converting to a string and back to a UserIdentity again. Bug: T382106 Change-Id: I2ce1a82f3fbb3cf18aa2d17986d46dbdcc70c761
* | Merge "block: Fix vague target requirements in BlockPermissionChecker"jenkins-bot2025-02-184-17/+62
|\ \
| * | block: Fix vague target requirements in BlockPermissionCheckerTim Starling2025-02-134-17/+62
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The doc comment of newBlockPermissionChecker() describes the $target parameter as being optional. The returned object does not need or use a target when checkBasePermissions() or checkEmailPermissions() are called. But failing to pass a target when calling checkBlockPermissions() is incorrect. This was the subject of the linked bug. If an admin is performing a block, self-unblock permissions need to be checked, this is not optional. This could be enforced at runtime, but it seems safer and simpler to enforce it statically. So, move $target from being a constructor parameter to being a formal parameter of checkBlockPermissions(). This formal parameter will be statically required after a deprecation period. Deprecate newBlockPermissionChecker() and introduce newChecker(), using a name with a slightly less than conventional verbosity to allow us to change the parameter order. There is no $target parameter to newChecker(). Backwards compatibility is supported by adding an internal mutator method setTarget(). This can easily be removed after the deprecation period is over. In Special:Block, checkBlockPermissions() was called with $target=null on form entry, meaning that the user could unblock themselves if the target was specified in the URL, but could not unblock themselves by searching with the form. This seems inconsistent. So allow blocked admins to see the search form, but show an error when they try to block or unblock someone other than themselves. Bug: T384716 Change-Id: I8c26cdcc9b87b74bc458fe731cf7f170a2607150
* | block: Add $wgAutoblockExemptionsTaavi Väänänen2025-02-181-1/+19
| | | | | | | | | | | | | | | | | | Add a new option to exempt users from autoblocks in the configuration, instead of editing a MediaWiki space page on every wiki. The use case for this is WMCS ranges (see T386689). Bug: T240542 Change-Id: I704b34b81214e7a1ac819fefa7ad3c2c87305647
* | block: Split exemption list parsing to separate functionTaavi Väänänen2025-02-181-9/+16
| | | | | | | | Change-Id: Ic8672d708ff5c558199e5233a4e3fc758d6ac023
* | block: Introduce AbstractBlock::isIndefiniteMartin Urbanec2025-02-142-0/+13
|/ | | | | | | | | | | | | | | | As far as I can see, the only way to determine whether a block has an expiry set is through comparing getExpiry() with the string 'infinity'. That feels fairly fragile, as well as really easy to make an error with. GrowthExperiments needs to introduce a specific behavior for only indefinitely blocked users. To be able to make that detection, the abovementioned method is being added. Bug: T351234 Change-Id: I85efcc71fe3a6d374b57abaefda8d1d370b41bd6
* Use $string === '' instead of strlen( $string ) === 0Fomafix2025-01-301-1/+1
| | | | | | | | | Add $string === false or $string === null where $string can have other types than a string. Also document null as possible return value in FileRepo. Change-Id: Iaa29ba01c3fd6bea506debdc6f929edfe881c808
* block: Fix unblock by ID of self-blockTim Starling2025-01-271-5/+6
| | | | | | | | | | | | | | When unblocking by ID, ApiUnblock passed the target to BlockPermissionChecker as a string, but the check for self-unblock requires a UserIdentity. UnblockUser passed the $target constructor argument to BlockPermissionChecker, but that is always null when unblocking by ID. Fix both and add tests. Bug: T384716 Change-Id: I26a634cbed8789dd9fca48655f41fdd8c7066007
* Merge "block: Remove the last vestiges of old ipblocks schema support"jenkins-bot2025-01-212-252/+81
|\
| * block: Remove the last vestiges of old ipblocks schema supportTim Starling2025-01-162-252/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Remove DatabaseBlock::getQueryInfo() and ::getRangeCond(), which tried to present the new schema with old aliases. This approach was not successful and nothing actually used this compatibility code, as far as I know. * Remove DatabaseBlockStore::getReadStage() and ::getWriteStage(), which were hard-deprecated in 1.43. * Remove the $schema parameters from DatabaseBlockStore::getQueryInfo() and getRangeCond(). They were always documented as temporary. * In DatabaseBlockStore::newFromRow(), remove ipblocks field alias support. Change-Id: Ia772d57270de24a6c2f854324a1e9fef36fa2ef9
* | Merge "DatabaseBlock deprecations"jenkins-bot2025-01-212-0/+22
|\|
| * DatabaseBlock deprecationsTim Starling2025-01-162-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Hard-deprecate all public DatabaseBlock methods which are simply a b/c proxy into a service method. Most were already soft-deprecated. * Hard-deprecate BlockManager::getUserBlock() * Move DatabaseBlockTest methods testHardBlocks, testT31116NewFromTargetWithEmptyIp, testNewFromTargetRangeBlocks, testNewFromRow and testInsertExistingBlock to DatabaseBlockStoreTest. * Move DatabaseBlockTest methods testBlockedUserCanNotCreateAccount and testBlocksOnXff to BlockManagerTest. Depends-On: I653d969a00d8f9732b347c2e409564d514acae67 Depends-On: Id603cf5959552847c99c222bfaa459ca260d6210 Depends-On: I539e4db644a882f6e4f363ffa1e483fd4b7950c1 Depends-On: Ied545f26fd657315682b0eb42da9e9dde73288d6 Depends-On: If38ec08111d40a261e34a63d67083b8faa862422 Depends-On: I527b8197cbe8085072b598c3b12621c63ddb9355 Depends-On: I0ba3fb90bc0512216cb2b3d7b5896f5de5232716 Change-Id: Ib0a3dbfa17c9250b6cec732a547b2ef0f70b2440
* | Remove 2-line PHPDocs that just repeat the types from the codethiemowmde2025-01-176-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Same as Ia294bf4 did for 1-line comments. This patch removes slightly more complex 2-line PHPDoc comments that don't add any new information to the code, but literally repeat what the code already says. They say "don't document the code, code the documentation", and we are doing this more and more. We just tend to forget to remove the obsolete comments. Note I'm also removing a line of text in a few cases when it's very short and literally says the same as the method name. Again, such comments add zero new information. Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
* | Remove trivial 1-line PHPDocs that just repeat the codethiemowmde2025-01-161-3/+0
|/ | | | | | | | | | | | | I assume these are all either auto-generated by an IDE or the language-level type declarations have been added later. In any case the comments don't add any new information to what the code already says. This is just extra clutter that makes the code harder to read, I would argue. There are many, many more comments like this. In this patch I intentionally focus on the most trivial 1-line comments. Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
* Merge "block: Update block action links in block log and contributions for ↵jenkins-bot2025-01-152-0/+4
|\ | | | | | | multiblocks"
| * block: Update block action links in block log and contributions for multiblocksTim Starling2025-01-152-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the new Codex block page is enabled: * In BlockLogFormatter, relabel the unblock link as "remove block". Link to Special:Block?remove=1 instead of Special:Unblock. * In BlockLogFormatter, pass the block ID to the special page using the "id" parameter if it is available in log_params. * In Special:Contributions and other special pages derived from ContributionsSpecialPage, if the user is blocked, combine the unblock/reblock links into a single "manage blocks" link. Also: * When blocking or unblocking, copy the block ID to log_params. Associations from log_search are not available to LogFormatter subclasses. There are many callers so copying this data is much easier than querying log_search. Bug: T378150 Change-Id: Ice0aa13291f8b38fc66d2a1524aef65ea17c8b27
* | Merge "ApiUnblock: Add support for multiblocks"jenkins-bot2025-01-143-16/+117
|\ \
| * | ApiUnblock: Add support for multiblocksDayllan Maza2025-01-143-16/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Re-purpose the existing id parameter to support block ID. If both id, and username are provided the request will fail * If a target has more than one block and a specific block is not provided it will fail with ipb_cant_unblock_multiple_blocks Bug: T378148 Change-Id: I04928d989e6764ac93ec243a5fec9c7fe2b0b9b0
* | | block: Fix HideUserUtils error when user is hidden twiceTim Starling2025-01-101-5/+3
| |/ |/| | | | | | | | | | | | | | | | | | | * Add a limit to the HideUserUtils subqueries to avoid error "Subquery returns more than 1 row". We really want to know if at least one row exists. * Fix outdated doc comment * Add tests. Bug: T382399 Change-Id: Ib3bc22e0b3080b3ae6e1d2591ac7f2a1ef57c6b3
* | Merge "block: Fix exception when purging multiple expired blocks for the ↵jenkins-bot2025-01-081-1/+6
|\ \ | | | | | | | | | same target"
| * | block: Fix exception when purging multiple expired blocks for the same targetTim Starling2025-01-081-1/+6
| |/ | | | | | | | | | | | | | | | | | | | | The loop releasing targets with different deltas did not account for the fact that there may be some deltas with no targets. An InvalidArgumentException was thrown. So, fix it twice and add a regression test. Bug: T382881 Change-Id: I7feac31891b5314daf20cec161fbadf7c5b4f8ca
* / block: Show a special log entry when blocking an already blocked targetTim Starling2025-01-072-52/+95
|/ | | | | | | "Sysop added a block for Target" instead of "Sysop blocked Target". Bug: T378150 Change-Id: I2febf1bcb57d014e48bd58eecbdecaa3c2f9c724
* block: Multiblocks block APITim Starling2024-12-164-64/+226
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In ApiBlock: * Add an "id" parameter. If this is given, update the specified block. * Add a "newblock" parameter. If this is given, always add a new block, don't check if the target is already blocked. * If "reblock" is given and the target has more than one block, fail with an "ambiguous-block" error. Supporting changes: * Add BlockUserFactory::newUpdateBlock(), which takes a DatabaseBlock instead of a target union to act on. The block is passed through to the BlockUser constructor. * Rename the first parameter to BlockUser::placeBlock() from $reblock to $conflictMode, and style it like an enum. Add the CONFLICT_NEW value, to support the "newblock" API option. * In DatabaseBlockStore::newFromId(), add $fromPrimary, so that ApiBlock can pass data to BlockUserFactory with equivalent freshness to the LHS. Also: * In BlockUser, memoize prior blocks loaded from the DB * Move T287798 autoblock check to the memoized accessor. Just don't return autoblocks. * Move "TODO handle failure" comment in BlockUser to the called method. It really can't fail. * In DatabaseBlockStore::newFromId(), add an $includeExpired parameter and default to false although it was previously implicitly true. Based on a brief review of callers, I think this is beneficial. Bug: T378147 Change-Id: Iea5b77cb27006b33f3dde61660be5ad2c374a425
* Fix bug in BlockManager::getUniqueBlocksDreamy Jazz2024-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | Why: * In 816920f74df8edc1b739eb6ea7ec9d7d6db64a8f, the BlockManager::getUniqueBlocks method was updated to fix a bug which caused a non-existing ::getParentBlockId to be called on an AbstractBlock instance. * However, this change introduced another bug that was not noticed. This was partly due to the changes to the tests not properly being made, such that the bug was not apparent. What: * Fix the bug in BlockManager::getUniqueBlocks * Update the relevant test to correctly check the output of BlockManager::getUniqueBlocks, by looking for the expected blocks instead of just counting the number that are returned. Bug: T378563 Change-Id: I397bf36c2ef891b0b8aadef0c0b12514ae0664a2
* [BlockManager] Don't assume autoblocks have ::getParentBlockIdDreamy Jazz2024-10-301-3/+1
| | | | | | | | | | | | | | | | | | | | | | | Why: * The BlockManager::getUniqueBlocks method assumes that any block instance which has the type of Block::TYPE_AUTO must be an instance of the DatabaseBlock class. * This assumption is incorrect, as extensions can implement autoblocks without extending DatabaseBlock (which is specifically for core blocks). ** This assumption failed for GlobalBlocking global autoblocks, which causes an exception to be met when a user tries to create an account while globally autoblocked. What: * Update BlockManager::getUniqueBlocks to only call the ::getParentBlockId method if the block is an instance of the DatabaseBlock class (which has the method). * Update the tests for this method to verify that the fix has worked. Bug: T378563 Change-Id: I8c8c21e2fd198a4097550d6714f473db59b11b3a
* Use explicit nullable type on parameter argumentsUmherirrender2024-10-163-3/+3
| | | | | | | | | | | Implicitly marking parameter $... as nullable is deprecated in php8.4, the explicit nullable type must be used instead Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a Break one long line in SpecialPage.php Bug: T376276 Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
* block: Invalidate sessions on BlockDisablesLogin blocksGergő Tisza2024-10-111-4/+2
| | | | | | | | | | | | | | Use SessionManager::invalidateSessionsForUser() rather then just resetting the user token when logging out a user who is blocked on a $wgBlockDisablesLogin wiki, so they are properly logged out even when an authentication extension like CentralAuth is active. Doesn't entirely fix the todo in that that it will invalidate sessions for the local user with the same name as the blocked user, and if that's a cross-wiki user there's still no guarantee it is the same user. But in practice it's unlikely not to be. Change-Id: Ic48814fcfeb71ca0736bac5f133ff407cf494021
* Remove meaningless @var documentation from constantsthiemowmde2024-10-091-2/+0
| | | | | | | | | A constant is not a variable. The type is hard-coded via the value and can never change. While the extra @var probably doesn't hurt much, it's redundant and error-prone and can't provide any additional information. Change-Id: Iee1f36a1905d9b9c6b26d0684b7848571f0c1733
* Add SpreadAnyEditBlock hookDreamy Jazz2024-09-241-0/+26
| | | | | | | | | | | | | | | | | | | | | Why: * A hook is needed which is called when User::spreadAnyEditBlock is called, so that extensions which provide alternative blocking mechanisims (such as the GlobalBlocking extension) can spread their blocks when local blocks are spread. What: * Add SpreadAnyEditBlockHook which is called from User ::spreadAnyEditBlock when it is called except when the user is not registered. ** The hook is called even if the user is not locally blocked * The return value of User::spreadAnyEditBlock is modified to return true if either a local block or alternative blocking mechanism spread blocks. * Update UserTest to test this new behaviour. Bug: T374857 Change-Id: Id302a6362d6177c89da9cdf4e677b3822ecb85f1
* Remove unchecked exception annotationsAdam Wight2024-09-171-2/+2
| | | | | | | | | | | | | | | Callers should not catch an unchecked exception, so it doesn't belong in a function signature. Unchecked exceptions indicate a coding error, which by definition the code will not be able to handle correctly. If any of these exceptions were supposed to be in response to an edge case, user input, or initial conditions, then they should be changed to a runtime error. If the exception class cannot be changed, then the annotation should include a comment explaining its purpose and prognosis. Bug: T240672 Change-Id: I2e640b9737cb68090a8e1cb70067d1b74037d647
* Fix some typosMatěj Suchánek2024-08-181-2/+2
| | | | Change-Id: I1a41f33c65bc9edf2df248581a2c45c5c79c4f93
* Move Language and friends into Language namespaceJames D. Forrester2024-08-101-1/+1
| | | | | Bug: T353458 Change-Id: Id3202c0c4f4a2043bf97b7caee081acab684155c
* Use real type hints for services etc. in includes/block/Bartosz Dziewoński2024-07-3113-292/+79
| | | | | | | | | | | | | | | | | Mostly used find-and-replace: Find: /\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|) Replace with: \3 \1 \4 More could be done, but to keep this patch reasonably sized, I only changed the most obvious and unambiguously correct cases. In some cases, I also removed redundant doc comments on the constructor, and re-ordered the properties to match the constructor. Change-Id: I819ed771c915293663856c577a481d607b76ed80
* Return early in BlockManager::trackBlockWithCookie if cookie blocks are disabledJayden Bailey2024-07-291-0/+6
| | | | | | | This prevents an unnecessary database lookup on every web request. Bug: T371249 Change-Id: Idc3035996fccbfc661580ba459fec8f44a0b526c