Use
$request->getRawVal( 'key' ) ?? 'default'
instead of
$request->getRawVal( 'key', 'default' )
The ?? is more flexible, avoids a wrong type detection by phan and
avoids the evaluation of the default value if not needed.
Bug: T376245
Depends-On: I3ed6b85c0d117ed7cb3a8b79f73a3eb42977891e
Change-Id: I8b02f9297b76d04e21f8cb9194f3b85631956eca
Add doc-typehints to class properties found by the PropertyDocumentation
sniff to improve the documentation.
Once the sniff is enabled it avoids that new code is missing type
declarations. This is focused on documentation and does not change code.
Change-Id: I1da4b272a6b28c419cc8e860d142dae19ca0bbcf
Provided arguments already have type declaration on the construtor
and it is safe to use the same type on the class property
Change-Id: Ia8bbdc4dee59dfb487582dd514486ec8542951be
wfGetUrlUtils() is also deprecated, but less so, so we can do this first
and then properly replace the individual uses with dependency injection
in local pieces of work.
Also:
* Switching Parser::getExternalLinkRel to UrlUtils::matchesDomainList
exposed a type error in media.txt where $wgNoFollowDomainExceptions
was set to a string (which is invalid) instead of an array.
Bug: T319340
Change-Id: Icb512d7241954ee155b64c57f3782b86acfd9a4c
It didn't have any use outside the core so went for the removal
instead of raising warning and hard deprecation.
Change-Id: I08dab348a89f1fe1adccfad4f003d9fb8b233f0d
wfGetServerUrl is deprecated since 1.39, let's remove the
only use and turn it into a hard deprecation.
Change-Id: I82be851fe411cd002c9c5847fe3924a6c0a4ba50
Given a cookie header like "Cookie: foo[]=bar;foo[]=bar2', PHP will
assign $_COOKIE['foo'] = [ 'bar','bar2']. This is not expected by
callers in MediaWiki and can trigger various errors in code that does
not expect to be dealing with arrays in this situation, nor is it
specified by RFC 6265[1] or any of its predecessors. So, stick to RFC
semantics here and treat the cookie as absent, since the name foo[] is
not the same as foo.
[1] https://datatracker.ietf.org/doc/html/rfc6265
Bug: T363980
Change-Id: Idaa175234de2d25a90e6be8fb6279c39089726bd
It wasn't at all obvious to me what $request->getText()
and similar actually get. I noticed that all of them read the
$this->data variable, and the comment for that variable
states that it is the $_GET, $_POST, and path router data,
so I have explicitly added this to the comments for each
related get method.
Change-Id: I89ad4016622bbc6c8c3abf5e47d273e19b38d5dc
This moves a code out of file scope into classes to make it
testable. The code is left in the same structure as it was before,
global functions have been converted into methods on the new
ThumbnailEntryPoint and Thumbnail404EntryPoint classes.
This test introduces comprehensive phpunit tests covering all functional
code paths in ThumbnailEntryPoint. This is intended to support
refactoring of this code.
Change-Id: I459abc7b11d0ab4ee682a863c9525a945048296f
In MediaWiki 1.41.0 the function WebRequest::detectServer() started to generate server URL strings containing default ports such as 80
for http and 443 for https.
Before 1.41.0: https://my.wiki
After 1.41.0: https://my.wiki:443
detectServer() uses IPUtils::combineHostAndPort() to build the URL. The
latter function has actually a mechanism built in that intends to omit
standard ports, so the new behavior in MW 1.41.0 seems unintended.
As this broke WDQS over here in our Wikibase Suite bundle, I
investigated the cause.
MediaWiki 1.41.0 updates IPUtils from 4 to 5. With this update, there
was a change that compares the port now via === instead of ==.
(e68cf6a14e%5E%21/#F1
Line 383) The new behavior is correct, as the function expects an int.
MediaWiki passes in a string though. This bug was hidden with IPUtils 4,
but is triggered now in IPUtils 5.
I think this should be backported to REL1_41.
Change-Id: Ib707ee72e02cf99225168d268d5fedab3f548ead
Bug: T360608
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I24ca752d5dac7c948fdbcabf721f6f0aef8a466f
* Switch out raw Exceptions, mostly for InvalidArgumentExceptions.
* Fake exceptions triggered to give Monolog a backtrace are for
some reason "traditionally" RuntimeExceptions, instead, so we
continue to use that pattern in remaining locations.
* Just entirely give up on PostgresResultWrapper's resource vs. object mess.
* Drop now-unneeded false positive hits.
Change-Id: Id183ab60994cd9c6dc80401d4ce4de0ddf2b3da0
Updating name & email addresses for Brooke Vibber.
Re-ran updateCredits.php as well so there are some new entries in
there as well.
There are a couple of files in resources/libs that will have to
be changed upstream to keep tests happy, I will do patches
later. :D
Change-Id: I2f2e75d3fa42e8cf6de19a8fbb615bac28efcd54
While not formally specified in the Stable interface policy, it is
imho not recommended to deprecate a method in a stable class with a
pointer to a method in an `@unstable` class. This sends a mixed signal
to developers.
Keeping this as wrapper method is harmless either way, but I suggest
removing this so that we do not create send automatic nudges to
contributors to change existing code (yet).
Bug: T346211
Change-Id: Iddf8f286e3ffdfce32a8fc2cc95a4e1d4893e146
* Deprecate the wgUseSameSiteLegacyCookies configuration variable and
imply false (the previous default).
* Deprecate WebRequest::getCrossSiteCookie(), which was introduced to
support this feature.
* Ignore the sameSiteLegacy option if it is passed to
WebResponse::setCookie() or mediawiki.cookie.set(). The configuration
variable can't be removed until the after the JS change is deployed.
Bug: T344791
Change-Id: I30392ebc02809bc6b6ee2070d3e468e48d5d1fae
1) Introduce EntryPointEnvironment which wraps functions that interact
with the PHP runtime, so they can be mocked for testing.
2) Allow server info fields to be overwritten in FauxRequest.
3) Make MediaWikiEntryPoint use WebResponse to set headers
Bug: T354216
Change-Id: Ic21950c956de5d2b5a7dd66a1e2de58f807cfd9f
Soft-deprecated since 1.35 and hard-deprecated since at least
I9776d11d4e2d184 (1.39).
Not set in production.
Change-Id: I68b68ffcdff22daafad34c186d1cc609dcecbf32
For readability. Allowed since PHP 7.4.
I searched for integer literals of 6 or more digits, and also changed
some nearby smaller numbers for consistency.
Bug: T353205
Change-Id: I8518e04889ba8fd52e0f9476a74f8e3e1454b678
Instead of only exposing the ability to send CSP headers, expose
the values of the headers so they can be set via other mechanisms.
Bug: T169027
Change-Id: Ie9f7a29218392e3bc3215ce879ed2a3c48847a7c
WebRequest::getFuzzyBool() will emit a deprecation warning on PHP 8.1 or
newer if the parameter to be fetched is absent and the $default value is
set to `true`, because strcasecmp() no longer accepts nulls. Fix it by
returning out if the parameter is wholly absent and add a test for this
scenario.
Bug: T351088
Change-Id: I85bbfec6aabef4e85859a76b6e50c80781024ae5
Deprecated methods are:
* WebRequest::isSafeRequest()
* WebRequest::markAsSafeRequest()
Introduced in I43f4bc06c19d823d7d1f (549af8bf) and used in
I01ae2f045726208d2af7 (ce3a25be), then later removed in I4eb10817cccb40aa255
(e34fd634) which became unused in core.
As a result, it made markAsSafeRequest useless as there is really no
consumer at this point.
No known usage (confirmation) per our code search tool today. See below:
https://codesearch.wmcloud.org/search/?q=isSafeRequest&files=&excludeFiles=&repos=
Change-Id: I39cfb04c46374153d374fe0bb88690fa48ad7250
These are the same as taint-check's MediaWikiSecurityCheckPlugin.php.
The notable exception is methods in WebRequest that were previously
hardcoded as returning a safe value. This was a consequence of said
methods return safe types (e.g., int, bool). Instead of adding
taint-check annotations, add return typehints instead, which let
taint-check remove any taintedness.
Fix some taint-check issues that were previously not spotted or whose
suppressions were removed in other patches.
Also fix the following bugs spotted by phan thanks to the type hints:
- SpecialExport did not have explicit handling of null $depth, and just
returned 0 because null fails both the < and the > comparisons.
- Improve documentation of params and props in ProtectedPagesPager.
SpecialProtectedPages can pass null $namespace and $size.
- Remove unused parameter from SpecialProtectedPages::showOptions, of
which $ns and $size were not documented as nullable.
- Add FIXMEs in SpecialVersion about very inconsistent escaping.
Bug: T321806
Change-Id: I726f528856614c92329683a0ad8936a42e262748
With OpenTelemetry standard we should inject all `X-Request-Id`,
`tracestate` and `traceparet` headers to MediaWiki response.
Bug: T340573
Change-Id: Id0343fc8fdc04c21bb5067df7e643ca9cfb68abb
The "nonce" CSP feature has been never been properly tested and is not
on track to be enabled at WMF or in MW by default. The use of
nonce-protected eval is not particularly meaningful. It is trivially
bypassed by mw.loader.implement, mw.loader.store, or importScript();
all of which allow any code to be executed directly, or to be stored
and loaded from a first-party origin.
The "nonce" feature is not required for the T208188 roadmap, and with
change I51b8535b2b21a3 there is now also a (small) performance reason
to keep this disabled long-term.
Until and unless there is a plan for enabling this particular aspect
of CSP, we might as well remove it so that we don't waste time our
time building abstraction layers and satisfying dependency injection
through many years for something that might never be used.
Note that this does not remove CSP support from ResourceLoader, and
does not take away from the future of enabling CSP in MediaWiki to
e.g. strictly block third-party scripts, or to require domains to
opt-in by site config or user pref (T208188).
Change-Id: I5a176c41a06a484a11e64bdacdc42b40811fe72e
Introduce a Telemetry singleton for propagating `tracestate` and
`traceheaders` during a MW web request. This class allows for easier
testing and mocking.
In the future we might use this as a wrapper for OpenTelemetry.
Bug: T320559
Change-Id: I3e5e54afa21f8c099877b3765c769f2d2f8f5d61