DatabaseBlock methods for handling block cookies are deprecated, so
stop using these methods in tests and throw warnings.
Change-Id: I2b5cfd579aa14bbfc7a292587a288ee5032eb5ab
The motivations behind this change is T227892 and that a blocker for a System or
Composite block provides no useful information for the end user.
Here is what's changing:
* Move the $blocker property to DatabaseBlock, since this is the only type of
block that can be created by a user.
* Move handling of the 'by' and 'byName' constructor option from AbstractBlock to
DatabaseBlock.
* getBy(), getByName(), are now abstracts methods and each block type have to provide
their own implementation
* getBlocker(), setBlocker() are being deprecated in AbstractBlock and moved as internal
methods into DatabaseBlock
Bug: T227892
Depends-On: Ie2aa00cfec5e166460bcaeddba3c601fe0627c13
Change-Id: I1b17c652b12d98de3d996d309d4d3f22074be411
Autoblock reasons are built as a Message which takes the original
block's reason as a parameter. If the autoblock's reason is set using
the Message, it will be stored in the database with templates
expanded due to how a CommentStoreComment is constructed. Instead,
set the autoblock reason using a string with the unexpanded template.
Follow-up to 6a8920d3, which fixes how the reason is displayed in the
UI, but still expands the templates on saving.
Bug: T236501
Change-Id: I67a9941a9c039331576cbfc2ab58d9f20a7213e2
This reverts commit 5f06efb318, which
reverted 9335363789, which makes
the deprecated property AbstractBlock::mReason private.
After 9335363789, AbstractBlock::mReason is obsolete, since the block
reason is now stored as a CommentStoreComment, AbstractBlock::reason.
Change-Id: Ica0a74be90383689ca8e4cfe6d0fb25c9a5942c5
This reverts commit 9335363789.
Reason for revert: It's full of code accessing AbstractBlock::mReason
out there, see [1]. Also, it was never hard deprecated. While that may
be acceptable under some circumstances, it's definitely not OK to remove
code when there are consumers around. I'd have fixed it right now without
reverting if it were a single repo, but there's just too many.
[1] - https://codesearch.wmflabs.org/search/?q=-%3EmReason&i=nope&files=&repos=
Change-Id: I8669f502b50cff89e28dada0f65fe2b130ae9b37
AbstractBlock::setReason now accepts a string, Message or
CommentStoreComment. The CommentStoreComment is accessed via
AbstractBlock::getReasonComment.
AbstractBlock::getReason returns the reason as a string, with
the language and format consistent with how block reasons were
built before this commit. This method is deprecated, since it
makes assumptions about the language and format needed. The
deprecated mReason property is no longer public.
Doing this (and T227005) will remove the implicit dependency of
BlockManager::getUserBlock on language, which causes a recursion
error if the block is checked before the user has loaded. It also
provides a mechanism for getting the block reason in a language
specified by the caller. (This does not apply to DatabaseBlock
reasons entered via the Special:Block form, which were not and
are still not translatable.)
This commit also updates authentication classes to return the
translated reason.
Bug: T227007
Change-Id: Iec36876e930dff96a256aebbdc39cbfb331c244e
Follow-up to 235cade5a3: if a block cookie already exists, do nothing
if shouldApplyCookieBlock determines that the block should apply to
the user.
Bug: T233595
Change-Id: I85b7e1153225770218e5ea1607b46fa7ed7d8101
Before this commit, clearing a block cookie happens as a
side-effect of checking for a block cookie. After, a block cookie
is cleared if trackBlockWithCookie finds that there should be no
block cookie, but there is one.
Bug: T233595
Change-Id: Id5777361f95c60d2849cacba82f2ed9add647abf
The main reasons for adding this service layer are:
* It allows error messages to be more consistent, by defining
a set of reportable information that can describe any block
type and is consistently formatted.
* It decouples formatting from the block classes, removing
their dependency on language, for the most part.
The service provides one public method, getMessage, which
returns a Message object whose key and parameters are
determined by the type of block. This should be used instead
of the deprecated AbstractBlock::getPermissionsError and
AbstractBlock::getBlockErrorParams.
Calls to AbstractBlock::getPermissionsError are replaced in
this patch.
Bug: T227174
Change-Id: I8caae7e30a46ef7120a86a4e5e6f30ae00855063
The target and type of a block can theoretically be set to null via
AbstractBlock::setTarget, which calls AbstractBlock::parseTarget,
which can return null for the target and type.
Change-Id: Id8ec4ad6ff8f73b475793bb47ca95227ac2085e1
This was previously hardcoded from three places: 1) Upon viewing EditPage,
2) Upon viewing SpecialCreateAccount, 3) For any url if the user is
logged-in (User::loadFromSession/isLoggedIn).
== User::loadFromSession
Performing cookie blocks from here created a circular dependency because
Block may need the user language for localisation, which is determined by
asking the User object. This was previously worked around by using a
DeferredUpdate (T180050, T226777). Moving this logic explicitly to the
end of the pre-send cycle in MediaWiki::preOutputCommit breaks the cycle.
This is also where other request-specific handling resides already.
== Limited effect on unregistered users
When an unregistered user performs an edit, and gets blocked,
the cookie block is not applied until they open built-in editor
or CreateAccount page. This makes it more likely for a user's
IP to change meanwhile. Either intentionally, or simply due to
IPs varying naturally (e.g. between mobile locations, or when
going on/off WiFi). By applying it throughout sessioned page
views for unregistered users, it is more likely to get set.
Similar to what was already done for logged-in users.
This commit also makes the intent of not caching EditPage and
SpecialCreateAccount explicit. This was previously implicit
through nothing having called setCdnMaxage() and/or due to
Session::persist being checked for by OutputPage::sendCacheControl.
Bug: T233594
Change-Id: Icf5a00f9b41d31bb6d4742c049feca0039d0c9d9
This is for classes with a single undeclared property - aside from
BlockManager: I3f51fd3579514b83b567dfe20926df2f0930dc85 removed the
declaration of $permissionManager without actually removing all uses.
Change-Id: Ic2a95f77071312041be6e0633ea9b5325e98de42
Blocks are checked from the User object. Specifically,
User::getBlockedStatus instantiates a BlockManager and calls
BlockManager::getUserBlock. However, checking the block often depends
on knowing more about the state than the User should know. As a result,
the global user and request objects were passed into the block manager
on construction.
Whether the global request object should be passed into a service
constructor is still up for debate, so this moves the check for the
global state back to User::getBlockedStatus for now. (Note that it
reintroduces the problem of the User knowing more about state than it
should.)
This change also makes clearer the cases in which
BlockManager::getUserBlock is called from the User.
Different blocks may be sought, depending on the user and their
permissions. The user may be:
(1) The global user (and can be affected by IP blocks). The global
request object is needed for checking the IP address, the XFF
header and the cookies.
(2) The global user (and exempt from IP blocks). The global request
object is needed for checking the cookies.
(3) Another user (not the global user). No request object is available
or needed; just look for a block against the user account.
Cases #1 and #2 check whether the global user is blocked in practice;
the block may due to their user account being blocked or to an IP
address block or cookie block (or multiple of these). Case #3 simply
checks whether a user's account is blocked, and does not determine
whether the person using that account is affected in practice by any
IP address or cookie blocks.
Bug: T231919
Change-Id: I3f51fd3579514b83b567dfe20926df2f0930dc85
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
CompositeBlock::appliesToRight checks $block->appliesToRight()
for each of the original blocks from which it is made.
AbstractBlock::appliesToRight returns:
* true if the block applies to the right
* false if the block does not apply to the right
* null if unsure
Before this, CompositeBlock::appliesToRight can only return true
or false. After this, it returns:
* false if false for all of the original blocks
* true if true for one or more original blocks
* null otherwise
Bug: T229417
Bug: T231145
Change-Id: Ie93b7691b57ac6a8f86b3641ad07a1d54babcd42
BlockManager::getBlockFromCookieValue accepts a UserIdentity, so should
only call methods defined in that interface.
Change-Id: If30df15b800cceee0ad052a2e0524df8b28d9901
Several block-related hooks allow the user to be put into in a state
that is inconsistent with blocks that can actually be made:
* With UserIsHidden, User::mHideName can be set to true without there
being a block
* With UserIsBlockedFrom, a user can be blocked from editing a page
without there being a block
* With GetBlockedStatus, public block properties can be arbitrarily
set on a user
These problems are mostly theoretical, but mean that it is impossible to
make some basic assumptions, e.g. that a user who is blocked from a page
must have a block. The hooks are not widely used, and with a few changes
we can make them more robust so such assumptions can be made.
This patch:
* Ensures UserIsBlockedFrom is only called if there is a block. This
would be a breaking change if any extensions were using this to block
an unblocked user; the intended use case is clearly for extensions to
allow user talk page access to blocked users.
* Adds a new hook, GetUserBlockComplete, which passes the block for
modification. This should be used instead GetBlockedStatus and
UserIsHidden, which will be deprecated in the future.
* Allows the 'hideName' option to be passed into the AbstractBlock
constructor so that suppressing system blocks can be made.
Bug: T228948
Bug: T229035
Change-Id: I6f145335abeb16775b08e8c7c751a01f113281e3
When a block cookie is present and the block is invalid or doesn't exists
or the cookie value is invalid or malformed, the cookie is removed.
Bug: T227678
Change-Id: Icaff594686c16a0eb8551b2a4392a14a969b43b0
Public methods for checking and setting these properties already
exist where needed. Also update the remaining direct uses of these
properties in core.
Change-Id: Icdef025c9700e625aeb2a07975e69f1b1cc2466c
For any messages that use CompositeBlock::getPermissionsError, include
details of the original blocks from which the composite block is made.
If there are any database blocks, give their IDs and also explain that
there may also be blocks due to IP blacklisting.
If there are no database blocks, then explain that the IP must be
blacklisted in multiple places.
Bug: T212326
Change-Id: Id6ad0019f8add4d5e000da5e872338e87cca485e
This is the preferred method as it enforces read-only mode for DB_REPLICA
and handles LoadBalancer::reuseConnection() calls automatically.
Change-Id: Iab9439ba8e0810fa14c302661ed7a3534f6bfc0d
