This reverts commit c17ddfd786.
This time, also: Trying to get mock http to work in parser test
Bug: T262443
Change-Id: Id708cdfa3d3c27f30543c6bf212df96e6b0a69e1
Tests should not make real HTTP requests. Mock out the
HTTPRequestFactory service to prevent this.
Bug: T262443
Depends-On: I63bfd54c3de55d678e8b862b85c0adfb5fc94d91
Change-Id: I1702c11928f8760bb41b41f4c7c04d7af03f62e2
MockHttpTrait can be used by tests that need to simulate HTTP requests.
Bug: T262443
Needed-By: I1832cb1858ef4cf42ec34cb7fda509ce5b951c27
Needed-By: I390856b4609635cee22253071f21ce63ff716791
Needed-By: Iff24b55dfaf7a4e02a4c80aaeaf0366de5660ef1
Needed-By: Ia8213725839e4b697c4985060bc35593fea622bc
Change-Id: I8ce17da7315b87b8dd0e502e601b9ac488089456
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
* Makes ParserCache take the root of the key
as a constructor argument
* Introduces a ParserCacheFactory
Next steps:
- convert FlaggedRevs to using this.
- cleanup
This assumes that we wouldn't want to differentiate
the parser cache settings per use-case, as it is now
for default vs flaggedrevs caches. There are only two settings:
$wgParserCacheType - name of the BagOStuff to use
$wgParserCacheExpireTime - the expiration time.
I think if we wanted to have different settings for different
caches, we could add that as a next step.
Bug: T263583
Change-Id: I188772da541a95c95a5ecece7c7dd748395506c2
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
firejail has an RCE in its handling of --output when dealing with untrusted
arguments (CVE-2020-17367 and CVE-2020-17368). We can avoid this issue by
preventing shelling out to firejail if any parameter starts with '--output'.
Bug: T258763
Change-Id: Ic6a5644566a51a948de7b42daf57b29ced3daff4
This reverts commit a4dc6d82af.
I've reverted the merged patch since I didn't do enough testing
on serialized/reserialized ParserOutput and CacheTime. Now I'm
confident serialization/deserialization works.
Changes since original reverted version:
- Use __get/__set instead of DeprecationHelper in order to
avoid $deprecateProperties array to be serialized.
- Add test for old format serialization new format deserialization.
Change-Id: Ic911c2724ad709931d3316e609781fb89b5b7b28
I've been trying to find how -1 can actually get to
the cacheTime and could find any usages in core or
extensions. The proper way of making ParserOutput
uncacheable is to use updateExpiry( 0 ), that is
documented and has some warning about performance costs.
Setting the cacheTime to -1 seems to be an undocumented
feature (it is mentioned in comments as undocumented)
that doesn't seem to be used anywhere anymore.
I intend to remove it entirely after the deprecation is
deployed and we so not see any warnings for a few weeks.
Change-Id: Ie90b7e4a21faae726940fa9082f2e6a6ea8df613
When ParserOutput encounters a bad page title in an editsection
placeholder, this should not cause a fatal error. We can just not
produce an edit link and continue.
It's still worth logging though, since the parser shouldn't be putting
invalid links into editsection placeholders.
Bug: T261347
Change-Id: I154e85aec4b408e659e6281b02473c51f370865d
This is causing problems for Parsoid CI, as parser tests fail when
phpunit runs the tests at a different point than they are run in
core's CI due to the side-effects of content-language changes made in
other phpunit tests. (For example, phpunit runs all extension tests
after core tests, so the same parsertest can pass if included in core
and then fail when included in an extension.)
SpecialPageFactory::$aliases has a dependency on the current content
language, with no way to reset it other than to recreate the
SpecialPageFactory.
Change-Id: I278580ed5cf2c85403cbaf601f8af4753e14a9d0
This test case can fail if it doesn't all complete within the
same second. Set a fake time to avoid this.
Bug: T263606
Change-Id: Iad3916744685d48b863d09056967876666ec3c21
This data structure is sufficient to generate menus in
all Wikimedia deployed skins.
This new method will be used immediately in Example skin:
Ifb30a2c1314692c2869bd99c523e19c821be1f08
and Vector skin:
I5f7adc1840441b508ffee40139b85b64021789e6
Bug: T262098
Bug: T255924
Change-Id: I1a163cac0bff7620dcac50350cb6b93445a0cfbc
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
The TestListener interface is deprecated. This replacement has the
downside of using a public static property, but there seems to be no
other way to pass extra data to the printer (BTW: the ResultPrinter
class is internal, so it'd be even better if we could avoid subclassing
it).
Bug: T243600
Change-Id: I083146b7336ac09dfd077c8e6817553738282662
Creates an OPTIONS handler that handles any OPTIONS requests that are
not already handled by a handler. CORS has no mechanism to ensure the
user is authenticated, so the Router will reject cross-origin requests
from anon users.
This change allows authenticated users to make cross-origin
requests if they authenticate with OAuth or if
$wgRestAllowCrossOriginCookieAuth is enabled.
Bug: T232176
Bug: T262712
Change-Id: I128b4bdbec4f6bea35142153c951fd7b79617106
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 97e2c97578) predates
AbstractBlock::parseTarget (added in f64f960d9a). The callers being
updated here called getTargetAndType since before parseTarget was
available.
Bug: T250940
Change-Id: I366e1076b10ab7c2dc4bb04920908b3286b77b73
The headers passed to Guzzle via the Client constructor are termed
"conditional", meaning that headers in the Request override them. If you
set a "body" option containing a MultipartStream, it sets a default
Content-Type request header, overriding the one from the Client
constructor. So to send a multipart stream with a custom Content-Type,
it is necessary to pass headers to Guzzle in the Request object.
Change-Id: Ie7bfc548ce4211fbf3ec67e3913bbdd3482977c3
This commit deliberately does not add
any tests for the old, processUnblock
method, for the following reasons:
* The method is not actually used anywhere
in Gerrit (according to Code search), so there
is no proof of this deprecated functionality
to be used in any extension. While it may be used
in unpublished code, that should be rare enough,
covered by the service's tests. The processUnblock
method is also extremely trivial, and the probability
of making a mistake directly in it (so it wouldn't
be noticed by service's tests) is little to none.
* Even this patch technically decreased the
test coverage, it actually increases it a lot.
Prior to this commit, if someone makes a bug
within SpecialUnblock (ie. outside of UnblockUser
command object), it would go unnoticed by our tests.
That is because our current coverage of
the special page does not execute the special page
itself (comparably to what a real request would do),
it calls processUnblock method directly. That method,
however, is not called by the special page at all.
I believe that accepting a very slight lowering
of the test coverage (basically only for an academical
case only) is only a minor and temporary disadvantage.
This method will be soon (in next release) removed
for good, so this doesn't really contribute to
the long-term technical debt.
A proper long term solution for similar issues would
be to write proper unit tests for this special page.
Bug: T250020
Change-Id: I8223420989edab2a20725425531d2d5462a4f32a
Before this commit empty Monolog loggers (or at least when no handlers are
defined) were assigned (by Monolog 1.x) the stream handler php://stderr with
the level 'debug'. This whole behaviour from MediaWiki config to Monolog is
unexpected; in the outcomes, depending on the PHP execution program, stderr
is or is not saved somewhere by default, leading to very different behaviours.
The behaviour will change in Monolog 2.x and nothing will happen is such cases
(similar hence to a NullHandler). With this commit the behaviour is uniform
accross all environments and (future) Monolog version: nothing is logged if
no handler is defined.
Precisely, a NullHandler for a given logger/MediaWiki logging channel is
defined here either when there is no key 'handlers', either when this key is
an empty array or 'false'.
Bug: T196906
Change-Id: I124391cc7b4485081980c5015431404234f40073
As per https://www.php.net/manual/en/function.libxml-disable-entity-loader.php
this is technically unnecessary.
>However, as of libxml 2.9.0 entity substitution is disabled by default,
>so there is no need to disable the loading of external entities.
See also https://github.com/php/php-src/pull/5867
>Since the release of libxml 2.9.0 in 2012 external entity loading is
>disabled in libxml by default. This means that using
>libxml_disable_entity_loader() is no longer needed.
Hopefully helps prevent false positive reports from security scanning tools.
Change-Id: I8a09d62a9920fd0bf4a388baa5544a02323bb541
This covers only directly used services by this special page and pager
Services used by the base class are not part of this patch set
Bug: T259960
Change-Id: Idb534bfbf0c4db20bbd0564c44d7ebbd1e4d04a5
To ensure the functionality doesn't break as part of
Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab,
which refactors the block handling
Bug: T189073
Change-Id: I7cb1be6532c5b32a4a77924c42483d43a290c464
Also soft deprecate the old function. Replacing usages will be done
in a follow-up patch.
Bug: T263327
Change-Id: Iffa9337f3c5bd198693fdf51be55c4b1ecfacaf6
Apparently, SpecialBlockTest::testProcessFormUserTalkEditFlag
attempted to save a block that ended up to be empty, because it
didn't block any action and it didn't have any restriction, when
userTalkNamespaceBlocked was false (see lines 394-396 of the test).
Surprisingly, that used to work well, without throwing
ipb-empty-block, which indicates SpecialBlock allowed empty blocks
for some time.
This was unraveled when moving blocking logic from
SpecialBlock to a new BlockUser service, cf.
Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab.
This is the same case as 600fdd68f1.
Bug: T189073
Change-Id: I8361a11c6f5717e6728634edac7b8ea69fba8521
Apparently, SpecialBlockTest::testProcessFormRestrictionsChange
attempted to save a block that ended up to be empty, because it
didn't block any action and it didn't have any restriction.
Surprisingly, that seemed to work well, without throwing
ipb-empty-block.
This was unraveled when moving blocking logic from
SpecialBlock to a new BlockUser service, cf.
Ifdced735b694b85116cb0e43dadbfa8e4cdb8cab. Once I moved
this check from SpecialBlock (lines 897-905), jenkins refused
to process this test correctly.
Bug: T189073
Change-Id: Ib3692ab83a3bd8c4aa2ee028e0404b758e89cb19
