We have a utility function for this, so let's use it.
What I don't understand though is why Sanitizer uses custom PHP implementations
for both tag stripping and entity decoding, instead of the built-in functions.
If there's a security reason for this or the built-ins are inadequate, that's
fine, but then that should be documented (and we should possibly ban usage
of the built-ins).
Change-Id: I2ba2ecd388cb3d9cd2360ecaa236f3d444f0eabf
MWExceptionHandler::rollbackMasterChangesAndLog() only logged exceptions
if there were already master changes. This is extremely problematic when
debugging, especially in situations like DeferredUpdates where they were
silently being swallowed.
This makes it log exceptions in all paths, erring on the side of logging
the same exception twice (theoretically it's possible I suppose) instead
of not at all.
Also make the method able to handle DBError exceptions, which most of
the callers seemed to be assuming. ApiMain was handling this explicitly.
Bug: T168347
Change-Id: I8739051f824a455ba669344184c3b11ac95cb561
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
If it's not a preflight, it's either a simple request or an actual
request after a preflight. But simple requests can only be GET, HEAD, or
POST, and we only return a successful response for a preflight if the
actual request is going to be GET or POST. So either way it shouldn't be
handled as CORS.
This also adds a response header to indicate to the end user why
something they probably intended as a CORS request wasn't handled as
one, to help with debugging.
And it renames a local variable that confused me when looking back at
this code.
Bug: T168558
Change-Id: Ia66c74e1cc8536c6c478237540abb4d7a98b9803
The module's summary will be used as the description of the value.
Since these are often very long lists, this also changes ApiSandbox to
collapse <dl> lists in parameter descriptions by default.
Bug: T123930
Change-Id: I205b68a52a94cae4c1cdf7ec9fd3e8a04d565919
ApiMain will add a header to indicate that lacksSameOriginSecurity()
forced the request to be processed as if logged out, and ApiSandbox will
detect this header to display a helpful message on the results page.
Bug: T165797
Change-Id: I56390b31563c75d83cf0a8ffb1b8e4f3283895f0
This has a number of implications:
* A deprecation warning is automatically generated if the value is used.
* action=paraminfo can list it in a machine-readable manner.
* It is automatically flagged in the help when message-per-value mode is
used.
* In values lists in the help, it's specially marked (currently
strike-through).
* ApiSandbox will mark it in the widgets (currently strike-through).
Deprecation of submodules is not automatically detected here, that's
left for a later patch.
Bug: T123931
Change-Id: Idad6377063e457f9352a99df5c7cc15b1563579e
