User shouldn't be serialized, but it sometimes still is,
so until we introduce NotSerializableTrait in User,
clear-out Authority memoization.
Change-Id: I641c2721de8c6ebe9bfcd87cfcebff60dc091126
My personal best practice is to not document @params when there
is a @dataProvider. I mean, these test…() functions are not
meant to be called from anywhere. They do not really need
documentation. @param tags don't do much but duplicate what the
@dataProvider does. This is error-prone, as demonstrated by the
examples in this patch.
This patch also removes @throws tags from tests. A test…() can
never throw an exception. Otherwise the test would fail.
Most of these are found by the not yet released I10559d8.
Change-Id: I3782bca43f875687cd2be972144a7ab6b298454e
Ideally, only User associated with the global request
should be associated with UserAuthority. For a random
user instance, not the current performer, checking permissions
should be based solely on user groups and perhaps an
existing block. Right now however, PermissionManager
is coupled with global request, so we still instantiate
a UserAuthority for non-current users. This mimics the
behaviour we've had before. As we refactor PermissionManager,
we will be able to replace Authority implementation in this case,
or even entirely prohibit non-performer authority.
Bug: T271459
Depends-On: Iebf2dca34eea751391d9740443c195287399aa5c
Change-Id: Ib094e498fd883db23f2763f171281b1c9e99217e
In order to break up cyclic dependency between UserGroupManager
and PermissionManager, introduce a lightweight service for checking
group permissions.
Bug: T254537
Depends-On: I99ab3a69c41b3ec6721f9504ad6c77d3122df591
Change-Id: I1acd55c07d07b4a0d43fd838e11374b6d9be98d9
The InterwikiLoadPrefix hook isn't compatible with Parsoid, as it is
unidirectional and doesn't support enumerating all valid prefixes
(T270444). Set/reset $wgInterwikiCache to mock the interwiki table
for parserTests and other unit tests instead.
This is a soft deprecation, as the used-in-production
Extension:Interwiki still uses InterwikiLoadPrefix, although not in a
way that would break Parsoid (since $wgInterwikiCache is set in
production).
Bug: T270444
Change-Id: If2507017c99c4ee42c104a0890bc45a84d7239d5
The problem was that when using $user->getBlock
within checkCondition (APCOND_BLOCKED) caused a infinite
recursion as calling getBlock eventually leads back to checkCondition.
The fix here is to stop using userHasRight as that is the cause of the recursion.
This also fixes testGetUserAutopromoteBlockedDoesNotRecurse test so it
shouldn't fail.
Bug: T270145
Change-Id: Ic751eba70730de286bbd55772bd7562459fb30b4
Some User methods fail if they are called before $wgRequest is
set. But according to the Setup.php comment, it is only set for b/c.
The global request object can be lazy-initialised at any time.
This is sufficient to avoid T263911 (loss/obfuscation of the $wgServer
error message).
In tests, try to keep $wgRequest and RequestContext::$request in sync.
Introduce MediaWikiIntegrationTestCase::setRequest() which sets both at
once, and use that instead of setMwGlobals() or direct assignment.
BlockManagerTest was accidentally exploiting the fact that the global
context request and $wgRequest were separate objects. Making them the
same causes session cookies to appear in the response, breaking the
cookie counts. Use a new response for the test.
Bug: T263911
Bug: T245940
Change-Id: I2be99f7251a837bc6b62be0b152038157dec10f2
These accounts are usually very old and User::getRegistration returns
null for them because user_registration is null. Treat these accounts
as old enough to be in the most experienced group and only decide
on edit count. Fix queries in recent changes to avoid comparisons
with nulls as well.
Also improve documentation of User::getExperienceLevel.
Change-Id: I6090cf9b9097069469e8e547b217f0d16f0fe372
My dev wiki has some settings for these globals,
which results in broken test
1) UserTest::testGetEffectiveGroups
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
- 0 => 'autoconfirmed'
- 1 => '*'
- 2 => 'user'
+ 0 => '*'
+ 1 => 'user'
)
Change-Id: Id062c92aefdf9381d7575ece95124d62ec315aa4
* Convert everything that is protected to be private,
since the class is not stable to extend
* Remove PasswordReset::$hookContainer, unneeded
Additionally, add missing UserFactory::newFromRow,
for now just a wrapper for User::newFromRow
Bug: T253432
Change-Id: I1de57a08605ff6e0d2be8e276b7fcb08934fb5da
User objects are apparently serialized somewhere, removing
the trait until this gets fixed.
Remove UserTest::testSerialization_fails to
allow this change for now.
Bug: T264363
Change-Id: Id804755653452dc94184e5e481efcac3053e6535
The NonSerializableTrait prevents object serialization via php's native
serialization mechanism. Most objects are not safe to serialize, and
NonSerializableTrait provides a covenient and uniform way to protect
against serialization attempts.
This patch applies the NonSerializableTrait to some key classes in
MediaWiki.
Bug: T187731
Bug: T259181
Change-Id: I0c3b558d97e3415413bbaa3d98f6ebd5312c4a67
Without this, a user created from an invalid user ID would end up
representing the current requests IP address, which may lead to
confusion. Using the reserved name "Unknown user" seems safer.
Change-Id: Icbfe7c3a561ac927713b610ac9a0b5e6b88bf2f0
Following 23c3c70d7f, soft deprecate the static methods on
DatabaseBlock that have been moved to DatabaseBlockStore:
* ::insert
* ::delete
* ::update
* ::purgeExpired
Update calls to the deprecated methods from core.
Change-Id: I1272eb978594fd4f386bda12cbc24131ad7d882f
This makes User::pingLimiter() include the expiry time in the payload of
the cache key that holds the current count. This allows us to ignore
stale counts.
Until now, we have been relying on the cache implementation to expire
the relevant keys in time. This however seems to fail sometimes.
Bug: T246991
Change-Id: Ifa3c558b4449f1ca133d0064781f26ac1bf59425
It's not the WatchedItemStore that throws this exception, but
really the methods in the User class that implement this behavior.
Hence it needs to be tested in UserTest. And documented. That was
missing before.
This patch also replaces some Title::newFromText with slightly faster
Title::makeTitle, if possible.
Change-Id: Id930a547329145c0703b4c97773a49fd78dd6332
"user" style rate limits can't be cross-site, since they are based on
the user ID. "user-global" uses CentralIdLookup to allow cross-wiki
rate limits.
Bug: T251661
Change-Id: Id680b96be2ea81d29447c4c1abafc8f98a339626
This is going to fix the bug, but it's not going far enough, READ_LATEST
needs to be bumped to READ_EXCLUSIVE.
The problem is that the options mananger cache serves dual purpose:
on option lookup it's a cache, while it also holds the modifications
made to options before saving. We need to require the options fetched
with READ_EXCLUSIVE before we are going to save them, and not discard
the options cache if they were already read with READ_EXCLUSIVE. Relying
on the callers to use correct query flags seems very prone to errors.
Before this was handled with User::getInstanceForUpdate. I wonder if we
should establish a similar pattern and remove the query flags from the
individual methods paramaters, but establish that UserOptionsLookup
service, responsible for reading-only, will use replica DB, while
UserOptionsManager will use master and do locking reads. The usage
pattern would then be - if you only need to read the options, use
lookup. If you have an intention of modifying the options - grab
and instance of the manager, and go into master by default. Thoughts?
Bug: T255842
Change-Id: I399ab0da8880320fd9d5f725ead8a62026cd7b7d
The method UserEditTracker::getUserEditCount (as well as the old User class
logic it replaced) calculates the user's edit count and writes it to the
database if it was not computed yet. However, it attempts this write even if
MediaWiki is in read-only mode, causing errors as this method is frequently
called on read requests as well.
As a fix, move the edit count initialization to the job queue, which will avoid
trying to open a source DB connection (and thus cause a read-only error) on
installs that do not use the DB-based job queue. This change requires a
workaround in UserGroupManagerTest.
Bug: T259719
Change-Id: I6d1c8e9038ae1f98f47bdb2495aecc21654b24c0
