aboutsummaryrefslogtreecommitdiffstats
path: root/includes/api/ApiBlock.php
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Add 'temp' to allowed user types in various APIs"jenkins-bot2023-11-301-1/+1
|\
| * Add 'temp' to allowed user types in various APIsThalia2023-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Why: * Before this task, when an API parameter specifies allowed user types, temporary users and permanent users are in the same category: 'name'. * However, it is useful to separate them out, and sometimes allow a permanent user but not a temporary user (e.g. ApiResetPassword, since temporary users don't have passwords). * We therefore re-defined the 'name' type only to refer to permanent (named) users, and add a new 'temp' type. * This fixes params that currently intend to allow temp users, and that use 'name' to do so, by adding 'temp'. What: * Based on a search for `UserDef::PARAM_ALLOWED_USER_TYPES`, add the 'temp' type where necessary. * The following were not updated, because they shouldn't apply to temporary users: - owners for includes/api/ApiQueryWatchlist.php, includes/api/ApiQueryWatchlistRaw.php - users for includes/api/ApiResetPassword.php, includes/api/ApiUserrights.php, includes/api/ApiValidatePassword.php Bug: T350701 Change-Id: If5ccf1d469327791acff74d013343307e411cca9
* | Move user options related classes into its own namespaceMartin Urbanec2023-11-291-1/+1
|/ | | | | | | | | | | | | There are a couple of user options related classes already, and the T321527 work on dynamic defaults is going to add even more. Let's move them into a separate namespace to make core a bit more organized. Old name is kept as an alias for compatibility purposes. Bug: T321527 Bug: T352284 Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
* Use real type hints for services etc. in api/ except ApiQuery*.phpBartosz Dziewoński2023-08-291-20/+7
| | | | | | | | | | | | | | | 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 Followed by some manual review to make sure I'm not changing too much, omitting some changes that looked too complicated and anything that caused test failures, and some whitespace fixes. Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
* ApiBlock: Report the correct value for 'hidename' in responseThalia2023-08-081-1/+1
| | | | | | | | | | Report what the block actually does, rather than what was requested, since these might not always match. E.g. a request to hide an IP address may result in a block being made that does not hide the IP address. Bug: T343749 Change-Id: Iebe62179cfc77835dca78ac672f9ba3edfadbfed
* Api: Fix some very old copyright statements for RoanJames D. Forrester2023-03-161-1/+1
| | | | Change-Id: I820a2d388922653a6a5b9048b0feaafbb4297d91
* Reorg: Namespace the Title classJames D. Forrester2023-03-021-0/+1
| | | | | | | | | | | | | | | | | | | This is moderately messy. Process was principally: * xargs rg --files-with-matches '^use Title;' | grep 'php$' | \ xargs -P 1 -n 1 sed -i -z 's/use Title;/use MediaWiki\\Title\\Title;/1' * rg --files-without-match 'MediaWiki\\Title\\Title;' . | grep 'php$' | \ xargs rg --files-with-matches 'Title\b' | \ xargs -P 1 -n 1 sed -i -z 's/\nuse /\nuse MediaWiki\\Title\\Title;\nuse /1' * composer fix Then manual fix-ups for a few files that don't have any use statements. Bug: T166010 Follows-Up: Ia5d8cb759dc3bc9e9bbe217d0fb109e2f8c4101a Change-Id: If8fc9d0d95fc1a114021e282a706fc3e7da3524b
* Reorg: Move Title-related classes to title/Amir Sarabadani2022-11-261-0/+1
| | | | | | | | | | | | | | These three classes: - TitleArray - TitleArrayFromResult - TitleFactory We need to move these and the rest of files under title/ to Title/ (and namespace them) but the patch will become way too big given that Title class is also one of them. Bug: T321882 Change-Id: Iac1688172ee457348a08a470c86e047571feb8e0
* Use short array destructuring instead of list()Tim Starling2022-10-211-1/+1
| | | | | | | | Introduced in PHP 7.1. Because it's shorter and looks nice. I used regex replacement. Change-Id: I0555e199d126cd44501f859cb4589f8bd49694da
* Call IContextSource::getAuthority instead of IContextSource::getUserUmherirrender2022-06-291-1/+1
| | | | | | | Change to use Authority object where possible to use the interface instead of implementation Change-Id: Ia7e9ce2a2f05ef2ae1cf981bf96faf48b04cf58d
* api: Replace numerous more deprecated constantsReedy2022-06-061-1/+1
| | | | Change-Id: I498a315b8b4b56d5e2f939e797adbe0487cd7d07
* api: Replace numerous deprecated constantsReedy2022-06-061-13/+14
| | | | Change-Id: I34ffcb70efbfa257da8dab6e0790aa0d697caf5b
* Use MainConfigNames instead of string literals, #2Aryeh Gregor2022-04-131-5/+7
| | | | | | | This covers all occurrences of /onfig->.*get( '/ in includes/. Undoubtedly there are still plenty more to go. Change-Id: I33196c4153437778496f40436bcde399638ac361
* Use PHP's [ $this, 'fn' ] callback syntax where possibleThiemo Kreuz2021-12-031-3/+4
| | | | | | | | | | | | PHP 8.1 will give us "first class callables" that look like e.g. $result = array_map( $this->fn(...), $array ); For now we can use $result = array_map( [ $this, 'fn' ], $array ); Change-Id: I7278c80c075d162da73aa45af1b6578310ce0624
* api: Handle invalid/non-existent titles in ApiBlockSam Smith2021-07-271-4/+13
| | | | | | | | Defer to the TitleDef type definition for page titles to validate values passed to the pagerestrictions parameter. Bug: T279689 Change-Id: Ia2e116d1bc476b178d85a6331dec17d7a8df74ba
* Convert BlockUtils::parseBlockTarget to UserIdentityAlexander Vorwerk2021-07-201-9/+5
| | | | | Bug: T286490 Change-Id: Ice96180690828bcf2efd60faf6ad10d64307713d
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 01:16:16 +0000