aboutsummaryrefslogtreecommitdiffstats
path: root/includes/api/ApiBlock.php
Commit message (Collapse)AuthorAgeFilesLines
* api: Inject services into ApiWatchlistTraitUmherirrender2021-07-061-3/+13
| | | | | Bug: T259960 Change-Id: I73596f8c924ec4a02a7042608d19a35f82bb752a
* api: Replace User::whoIs in ApiBlockUmherirrender2021-06-301-9/+8
| | | | | | Inject and use the new UserIdentityLookup service Change-Id: I56b0ba599b5e86f568a5d7db6d27776ba52e1dc5
* Allow partial action blocks to be made via ApiBlockThalia2021-05-041-2/+33
| | | | | Bug: T280522 Change-Id: I114e3c76cfb6dd2f79b5217aee4b3da34df00850
* Hard-deprecate AbstractBlock::parseTargetPetr Pchelko2021-03-191-2/+9
| | | | | Bug: T276610 Change-Id: I2f10ae5da1d9b1ca4aa20492b943e0c94d32a0b6
* Convert (Un)BlockUser to AuthorityPetr Pchelko2021-03-181-1/+1
| | | | Change-Id: I5084b5523f15b7d55b2f5dc67ae19ec7059799ad
* Use static closures where safe to useUmherirrender2021-02-111-1/+1
| | | | | | | | | This is micro-optimization of closure code to avoid binding the closure to $this where it is not needed. Created by I25a17fb22b6b669e817317a0f45051ae9c608208 Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
* Reduce SpecialBlock/Api logic duplicationAmmar Abdulhamid2021-01-221-6/+5
| | | | | | | Add PageRestriction::newFromTitle() to create from Title instance or title string. Change-Id: Id4c8117b916be05edc863bcd7a15c74fb28a833a
* ApiBlock: Add user watch only after block successAmmar Abdulhamid2020-10-061-4/+4
| | | | | | | | | | I believe it does not make sense to go on with peripheral action when the primary action did not succeed. If the blocker decides to attempt the block again, they can also decide whether to add watch or not at that time. Change-Id: I64880ce254e33378642bb9f1952c88ce490ef490
* Add WatchlistExpiry support to ApiBlockAmmar Abdulhamid2020-10-011-9/+43
| | | | | Bug: T248515 Change-Id: I253bcb5a74a65cbd9834b5eabcd1ed7a1993a5d9
* Ignore block restrictions if block is not specified as partialThalia2020-09-281-13/+12
| | | | | | | | | | | | | | | | In SpecialBlock, ignore restrictions if the 'sitewide' radio was selected. In ApiBlock, ignore restrictions if the 'partial' parameter was falsey. In both cases, ignoring restrictions means not passing them to BlockUser. This restores the behaviour prior to a656d03597d2, that a block is sitewide unless it is marked as partial, even if restrictions options are set. Bug: T189073 Change-Id: I4d2e08b744b9d59909ce24cc5f167b676478970d
* Pass correct parameters to BlockUser from ApiBlock and SpecialBlockThalia2020-09-231-1/+2
| | | | | | | | | | | | Pass 'partial' parameter from ApiBlock. Pass 'DisableEmail' parameter from SpecialBlock only after confirming it is set. Follow-up to a656d03597d29dedf37a962ec0fddf552609a8ef Bug: T189073 Change-Id: I5acbb1c5d49b216bb235936cd479829128beac77
* Introduce backend class for blocking usersMartin Urbanec2020-09-221-80/+75
| | | | | | | | | | | | | | Rather than having to do DatabaseBlock calls directly, and then ManualLogEntry calls to facilitate logging, let's create a BlockUser service, capable of blocking users and logging, optionally with permission checking. This should make blocking users easier for developers, for instance, AbuseFilter or CheckUser can easily benefit from this commit. Bug: T189073 Change-Id: Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab
* Remove unnecessary calls to SpecialBlock::getTargetAndTypeThalia2020-09-211-2/+3
| | | | | | | | | | | | | | | | Refactor this method to make clearer that it returns the return value of AbstractBlock::parseTarget and does nothing additional when called without a WebRequest. Update callers that do that to call parseTarget directly instead. SpecialBlock::getTargetAndType (added in 97e2c97578c) predates AbstractBlock::parseTarget (added in f64f960d9a4). The callers being updated here called getTargetAndType since before parseTarget was available. Bug: T250940 Change-Id: I366e1076b10ab7c2dc4bb04920908b3286b77b73
* Do not call SpecialBlock::canBlockEmail in ApiBlockMartin Urbanec2020-09-191-1/+28
| | | | | Bug: T263327 Change-Id: Ic63178ba1ac2756b5b305d4fa8ea53ab40f9b011
* Use UserNameUtils in ApiBlockUmherirrender2020-08-051-1/+3
| | | | Change-Id: I6f2a8847076dbf91055a1b98bd5a2af8ae833dc8
* Remove $wgEnablePartialBlocks config and always enable partial blocksThalia2020-03-041-29/+13
| | | | | Bug: T242912 Change-Id: Icf737140dd112dc4d222274ae40e225cb7a9d3fc
* API: Use ParamValidator libraryBrad Jorsch2020-02-041-0/+3
| | | | | | | | | | | | | | | | | This brings significant modularization to the Action API's parameter validation, and allows the Action API and MW REST API to share validation code. Note there are several changes in this patch that may affect other code; see the entries in RELEASE-NOTES-1.35 for details. Bug: T142080 Bug: T232672 Bug: T21195 Bug: T34675 Bug: T154774 Change-Id: I1462edc1701278760fa695308007006868b249fc Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
* Better grouping for code adding elements to arraysDaimona Eaytoy2019-09-031-1/+2
| | | | | Change-Id: I7cc8c810f0dcf1ee84b9d5f14967ec2568e3e0be Follow-up: I50377746f01749b058c39fd8229f9d566224cc43
* Unsuppress more phan issues (part 5)Daimona Eaytoy2019-09-011-0/+1
| | | | | | Bug: T231636 Depends-On: I6e5fba7bd273219b1206559420b5bdb78734aa84 Change-Id: I50377746f01749b058c39fd8229f9d566224cc43
* Replace User::isAllowed with PermissionManager.Petr Pchelko2019-08-201-1/+2
| | | | | | | | Covers root includes, actions, api, block, changes, changetags, diff and PermissionManager itself. Bug: T220191 Change-Id: Ic027d32f5dd8f4c74865df0c8a9fcf91123c889c
* SECURITY: API: Respect $wgBlockCIDRLimit in action=blockKunal Mehta2019-06-061-0/+5
| | | | | | | | | | | | | | $wgBlockCIDRLimit states how large rangeblocks are allowed to be for IPv4 and IPv6. The API now calls SpecialBlock::validateTarget() to perform that validation step. As a minor thing, SpecialBlock::checkUnblockSelf() is now called twice by the API, but that can probably be cleaned up at another time. Tests included. Bug: T199540 Change-Id: Ic7d60240d9ebd9580c0eb3b41e4befceab69bd81
* Rename Block to MediaWiki\Block\DatabaseBlockThalia2019-05-281-3/+5
| | | | | | | | | | | | Keep Block as a deprecated class alias for DatabaseBlock. Update calls to the Block constructor and Block static methods from external classes. Also update documentation in several places that refer to blocks as Blocks. Bug: T222737 Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
* Restore ApiQueryUserInfo::getBlockInfo() as a stub.daniel2019-05-111-1/+1
| | | | | | | | | | | Fixes unintended breaking change made by I84ed21641c44b2f65ebe. ApiQueryUserInfo::getBlockInfo() is restoed as a hard deprecated stub. This renames the method in the new ApiBlockInfoTrait to getBlockDetails. Depends-On: I9f40666a31bd4af50762c197c2ce5bf089a5e68c Change-Id: If47a93878f87d69800e5f305404c22528dac5e94
* Move ApiQueryUserInfo::getBlockInfo() to ApiBaseAmir Sarabadani2019-05-061-1/+3
| | | | | | | ApiBase directly uses this method causing a cyclic dependency between ApiBase and ApiQueryUserInfo Change-Id: I84ed21641c44b2f65ebe1980b0893d1846db3b34
* Deprecate User::isBlocked()David Barratt2019-04-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The method User::isBlocked() attempts to answer two questions: (1) Does the user have a block? (2) Is the user prevented from performing this action? The method can answer #1, but it cannot answer #2. Since User::getBlock() can also answer #1, this method is redundant. The method cannot answer #2 because there is not enough context in order to answer that question. If access is being checked against a Title object, all access checks can be performed with PermissionManager:userCan() which will also check the user's blocks. If performing all access checks is not desirable, using PermissionManager::isBlockedFrom() is also acceptable for only checking if the user is blocked. This method does *not* determine if the action is allowed, only that the user's block applies to that Title. If access is being checked without an existing Title, User::getBlock() can be used to get the user's block. Then Block::appliesToRight() can be used to determine if the block applies explicitly to a right (or returns null if it is unknown or false if explicitly allowed). If the user is creating a new Title, but the text of the title is not yet known (as in the case of Wikibase), access should be checked with Block::appliesToNamespace(). Bug: T209004 Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
* Remove reliance on Block properties being publicThalia2019-03-221-1/+1
| | | | | | | | | Use getters and setters for $mReason, $mTimestamp, $mExpiry and $mHideName; use Block::getType to check if a block is an autoblock instead of checking $mAuto; no change needed for $mParentBlockId, which is not accessed externally. Change-Id: I767ed44ce4c2e21f53962d75fb86891add2282f6
* Add namespace restrictions to Special:Block and APIThalia2019-01-221-0/+8
| | | | | | | | | | | | | | | | | | | | | | This adds a UI for blocking namespaces to Special:Block and a namespacerestrictions parameter to the block API. The number of namespace restrictions in a single block is not limited as page restrictions are. The checkbox allowing the blocker to specify whether the target can edit their own user page is normally disabled for a partial block, but is re-enabled if the block is to the user talk namespace. If the config $wgBlockAllowsUTEdit is set to false, the checkbox will not appear, and the target will not be able to edit their own user talk page if they are sitewide-blocked, namespace-blocked from the user talk namespace, or page-blocked from their user talk page. Bug: T204986 Change-Id: I9e231ad109d7285486ec332b26780339592b8df7
* ApiBlock: Avoid PHP warning when partial blocks are enabled but not usedBrad Jorsch2018-12-191-1/+1
| | | | | | | | | | If partial blocks are available but a sitewide block is being made, $params['pagerestrictions'] is null and implode() raises a warning. Since null casts to the empty array, it's easy enough to work around. Also add a test hitting this case. Change-Id: Id7e2559d7569031b7c1228adb0c0a14b3c1527c3
* Set API limits for page restrictions to 10Thalia2018-12-171-14/+2
| | | | | Bug: T212142 Change-Id: Ide0f2f86df2101194155be53a4b9012ddefbbcaf
* Update Special:Block to set Partial BlocksDavid Barratt2018-10-241-1/+41
| | | | | | | | Make the necessary UI changes to Special:Block in order to set/update partial blocks. Bug: T197109 Change-Id: Ib3067824b5dcbdd893ab1f165d169a35d0716cb2
* Improve test coverage for ApiBlock.php to 100%Aryeh Gregor2018-03-261-2/+2
| | | | | | | | | | | | | | The code coverage tool still reports that line 50 ("$status,") is not covered, but this is just a parameter to a function that is in fact called and does show up as covered, so I'm pretty sure it's a bug. I replaced a couple of sanity checks that reported "incomplete" on failure with actual assertions so that the test would fail properly if the sanity check failed. The testing could still probably be expanded considerably. Change-Id: Ib6ba7227af23bcb50c7e3bafb0b51395e8acf03f
* Remove "Created on" from file header commentsUmherirrender2018-01-261-4/+0
| | | | | | | | | It is the job of git and svn to provide this information/metadata. The form was different, some with short, some with long month name some with leading zero at the day, some without. The year is also present in the Copyright clause Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
* build: Updating mediawiki/mediawiki-codesniffer to 15.0.0Umherirrender2018-01-011-2/+2
| | | | | | | | | | | | | Clean up use of @codingStandardsIgnore - @codingStandardsIgnoreFile -> phpcs:ignoreFile - @codingStandardsIgnoreLine -> phpcs:ignore - @codingStandardsIgnoreStart -> phpcs:disable - @codingStandardsIgnoreEnd -> phpcs:enable For phpcs:disable always the necessary sniffs are provided. Some start/end pairs are changed to line ignore Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
* ApiBlock: Improve username validationBrad Jorsch2017-12-191-3/+3
| | | | | | | | | | | The current username validation lets any invalid username through, on the assumption that it's an IP address. We can do better: call the backend to get the actual type and target, and reject anything with TYPE_USER where the actual input name is invalid (regardless of underlying mangling for stuff like T31797). Bug: T183211 Change-Id: I676642eee1222447df22a1c32b24f55e6273bcec
* Make API documentation links language awareBaha2017-04-051-1/+1
| | | | | | | | | | | | | | Links generated by the API are now aware of the user's preferred language and will show documents in that language if available. To test, log in to mediawiki.org and set your language preference to 'es', then on an MediaWiki installation with this patch view the generated expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`. Each link to documentation on mediawiki.org should take you to its translated /es subpage, if one exists. Bug: T104518 Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
* includes/api: Replace implicitly-Bugzilla bug numbers with Phab onesJames D. Forrester2017-02-241-2/+2
| | | | | | | It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345" except where it doesn't, so let's just standardise on the real numbers. Change-Id: I49e2a10350a328a8572fcedd44012751a29e1068
* Merge "Add parameter to API modules to apply change tags to log entries"jenkins-bot2017-01-131-0/+12
|\
| * Add parameter to API modules to apply change tags to log entriesThis, that and the other2017-01-121-0/+12
| | | | | | | | | | | | | | | | Adds support for tagging log entries for the block, import, managetags, and move API modules, using a 'tags' parameter. Bug: T97720 Change-Id: I9d75d2cece317a7704c4bc6d734ad3cafe24544e
* | ApiResult: Add ApiResult::formatExpiry()Brad Jorsch2017-01-111-3/+1
|/ | | | | | | | This allows for removing $wgContLang from many API modules where it was only used to call $wgContLang->formatExpiry() in a way in which the results don't actually depend on the language. Change-Id: Ib0f25f288b9b87d2e4131297c552e5971696db87
* Block API: Allow blocking/unblocking by user's IDSubin Siby2016-12-131-8/+23
| | | | | | | | Add feature to block/unblock users by their ID. For this,a new parameter `userid` is added to block & unblock API request. Bug: T34496 Change-Id: I084a4e275cd937053c505cd388a365b316990ece
* API: i18n for warnings and errorsBrad Jorsch2016-12-061-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | | API warnings and error messages are currently hard-coded English strings. This patch changes that. With a few exceptions, this patch should be compatible with non-updated extensions: * The change to ApiBase::$messageMap will blow up anything trying to mess with it. * The changes to the 'ApiCheckCanExecute' hook will cause a wrong (probably unparsed) error message to be emitted for extensions not already using an ApiMessage. Unless they're currently broken like Wikibase. Bug: T37074 Bug: T47843 Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898 Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6 Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b Depends-On: I535344c29d51521147c2a26c341dae38cec3e931 Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
* Convert remaining array() to [] in APIReedy2016-02-291-2/+2
| | | | Change-Id: Ib44d59ff0cf0d6d8efc462671cac716dbead8ffc
* Convert all array() syntax to []Kunal Mehta2016-02-171-10/+10
| | | | | | | | | | Per wikitech-l consensus: https://lists.wikimedia.org/pipermail/wikitech-l/2016-February/084821.html Notes: * Disabled CallTimePassByReference due to false positives (T127163) Change-Id: I2c8ce713ce6600a0bb7bf67537c87044c7a45c4b
* API: Flag "user" parameters in various modules as type 'user'Brad Jorsch2016-01-091-1/+1
| | | | | | | | | | The API 'user' type accepts both user names and IP addresses, and applies normalization but not canonicalization. We should be using this on basically every user parameter to ensure that e.g. IPv6 usernames get uppercased. Bug: T122803 Change-Id: Ic67fb54061ac311e54f325b2a1a4658f43b8fef4
* Fix Generic.Files.LineLength phpcs failure in 11 files under includes/Amir E. Aharoni2015-10-031-0/+2
| | | | | Bug: T102614 Change-Id: I0d759be6ef568c2c6f28606d3002484ad77a1830
* API: Give block details along with errorsAlex Monk2015-06-171-1/+7
| | | | | Bug: T95072 Change-Id: I295d74d5f33e6dd1072a1e85710a02597a46e14d
* Change API result data structure to be cleaner in new formatsBrad Jorsch2015-04-201-21/+7
| | | | | | | | | | | Nothing in this patch should result in changed output for format=json or format=php except as noted in RELEASE-NOTES-1.25, and changed output for format=xml should be similar or cosmetic. However, other code accessing the result data directly may need to be updated. Bug: T87053 Bug: T12887 Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
* Clean up handling of 'infinity'Brad Jorsch2015-03-131-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a bunch of stuff that probably only works because the database representation of infinity is actually 'infinity' on all databases besides Oracle, and Oracle in general isn't maintained. Generally, we should probably use 'infinity' everywhere except where directly dealing with the database. * Many extension callers of Language::formatExpiry() with $format !== true are assuming it'll return 'infinity', none are checking for $db->getInfinity(). * And Language::formatExpiry() would choke if passed 'infinity', despite callers doing this. * And Language::formatExpiry() could be more useful for the API if we can override the string returned for infinity. * As for core, Title is using Language::formatExpiry() with TS_MW which is going to be changing anyway. Extension callers mostly don't exist. * Block already normalizes its mExpiry field (and ->getExpiry()), but some stuff is comparing it with $db->getInfinity() anyway. A few external users set mExpiry to $db->getInfinity(), but this is mostly because SpecialBlock::parseExpiryInput() returns $db->getInfinity() while most callers (including all extensions) are assuming 'infinity'. * And for that matter, Block should use $db->decodeExpiry() instead of manually doing it, once we make that safe to call with 'infinity' for all the extensions passing $db->getInfinity() to Block's contructor. * WikiPage::doUpdateRestrictions() and some of its callers are using $db->getInfinity(), when all the inserts using that value are using $db->encodeExpiry() which will convert 'infinity'. This also cleans up a slave-lag issue I noticed in ApiBlock while testing. Bug: T92550 Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
* Refactor out 'infinity' variantsJuneHyeon Bae2015-03-121-1/+1
| | | | | | | | Refactor out 'infinity' vartiant values which used in blocking and protecting actions. This patchset adds GlobalFunction wfIsInfinity. Bug: T68646 Change-Id: I60cc55a5bbd43c72916a1c2ea3807457d4e33765
* API: Fix access on getExamplesMessagesBrad Jorsch2014-10-291-1/+1
| | | | | | | ApiBase declares it protected, but for some reason I had made it public in all subclasses. Change-Id: I8a50d4f47e66c7f09137968d3941dc5cdc1d28e4
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 17:32:51 +0000