| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I0d8d2237500ed6f18439410c902d47c42e4119bc
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Add $auto parameter to DatabaseBlockStore::newFromTarget and
::newListFromTarget, to help callers filter autoblocks from result
lists.
Change-Id: Iad92d205517eb50ab0ce5e8caae58ee761fe19d5
|
|/
|
|
|
| |
Bug: T353458
Change-Id: I3cf44dfe5425f2efb8409c83571c427447b053af
|
|
|
|
|
| |
Bug: T389452
Change-Id: Id7a3f565821231647fe75a24e9ef7efeeb157c5d
|
|
|
|
|
| |
Bug: T353458
Change-Id: Ibe1810f1c71316a9124e1dc6ae405097dafd5267
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug: T388097
Change-Id: I89baf1b190cf9adefba9a232f57c957a2345f8e5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Change-Id: Ic8672d708ff5c558199e5233a4e3fc758d6ac023
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| |
| | |
multiblocks"
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* 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
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* 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
|
|\ \
| | |
| | |
| | | |
same target"
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
| |
"Sysop added a block for Target" instead of "Sysop blocked Target".
Bug: T378150
Change-Id: I2febf1bcb57d014e48bd58eecbdecaa3c2f9c724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I1a41f33c65bc9edf2df248581a2c45c5c79c4f93
|
|
|
|
|
| |
Bug: T353458
Change-Id: Id3202c0c4f4a2043bf97b7caee081acab684155c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This prevents an unnecessary database lookup on every web request.
Bug: T371249
Change-Id: Idc3035996fccbfc661580ba459fec8f44a0b526c
|