Since I72c5e6f86b7f081ab5ce7a56f5365d2f75067a78 it is part of the
contract of ContentRenderer::getParserOutput() that the render ID (and
other cache parameters) will be set when it returns.
(ContentHandler::getParserOutput() can set them even earlier if it has
custom content-based overrides.) We had a lot of temporary
backward-compatibility code "later" in the parse process to try to close
the barn door if some code path "forgot" to set them, but these are
unnecessary now.
This patch removes that backward-compatibility code in ParsoidParser;
there is similar remaining code in ParserCache etc. which can be
addressed in follow ups.
(For compatibility we do have to temporarily copy the render ID code
inside ParsoidOutputAccess::parseUncachable, but that class is
deprecated and will be removed.)
The HtmlOutputRendererHelper path which used to call
ParsoidParser::parseFakeRevision() is now replaced with a codepath that
goes through RevisionRenderer. In order to maintain the same behavior
of the ParsoidHandler, we have also added 'useParsoid' handling to the
JsonContentHandler. This support can perhaps be deprecated eventually.
Bug: T350538
Change-Id: I0853624cf785f72fd956c6c2336f979f4402a68f
Instead of creating a half-initialized helper and later calling ::init,
provide all the information necessary for the helper in the constructor.
This is facilitated by the fact that there already exists a factory
class, PageRestHelperFactory, which holds all the services required.
This affects:
* HtmlOutputRendererHelper::init()
* HtmlMessageOutputHelper::init()
* HtmlInputTransformHelper::init()
Change-Id: I1e1213597c6be012f2bc024c2b370c968ff3b472
This removes the last use of ParsoidOutputAccess in core, allowing it
to be deprecated and eventually removed.
Bug: T367074
Bug: T317018
Change-Id: Ica2c880e2e7c2b126aaea66a3e4be460b3f2234f
ParamValidator and TypeDef could so far assume that data coming from the
client was always a string. Since we are now using the same code to
validate fields coming from a JSON request body, we may encounter arrays
and other non-string values in places where strings are expected. In
that case, we should fail gracefully instead of crashing with a type
error.
Change-Id: I8a3f0c3299d36e1e93e0114abc0d1d15bac7b5f8
This patch emits deprecation warnings when extensions override
Handler::getBodyValidator() or otherwise use JsonBodyValidator.
Request body validation should be performed based on body parameter
declarations returned from getBodyParamSettings().
Bug: T358560
Depends-On: I8b12c9c9d5a73c620e3c5d035f815d7c951c7b30
Change-Id: I44b3395b8d2489c5e7ec8de0077fd7a7c9f49bfe
I believe this makes the code less brittle, and also makes it a bit
more obvious what these strings are meant to represent.
Change-Id: Ia39b5c80af4b495931d0a68fd091b783645dd709
And deprecated aliases for the the no namespaced classes.
ReplicatedBagOStuff that already is deprecated isn't moved.
Bug: T353458
Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
Edits made by temporary accounts could not be counted independently
when accessing `v1/page/Test2/history/counts/{type}`.
- Add a `temporary` case for page history revision counts.
Bug: T365673
Change-Id: Ib5279684e2843c84a56eea04721dc62700c12577
This switches from logging warnings when clients use string instead of
numbers in JSON requests.
Bug: T305973
Depends-On: I17f7d0b89cb584eef5a7203a8f26cb5b100e2abb
Change-Id: I2d00d320f59652040ff914005aad58bf3e724689
In JSON request bodies, empty strings should be accepted in required
string fields. So far, empty strings are considered as missing, which is
the default behavior for query parameters.
Bug: T305973
Change-Id: I97a9556bb440b9564e7d3618d189df4ef6f6725c
DEPLOY: watch the api-warning channel for misbehaving clients.
We are now using TypeDef objects for validating fields in JSON
request bodies. Since TypeDef was designed for use in the action API, it
assumes that all client data is originally supplied as strings. These
strings are parsed and converted to the appropriate type.
But for JSON requests, we don't want that. If a field is defined to be a
boolean, it should be required to be a boolean, not the string "yes" or
"0".
This adds an option to TypeDefs that triggers strict type checks for
booleans and numbers. This option is enabled for all request types other
than form data.
For now, the check does not trigger a validation error. It just logs a
warning. This allows us to assess how often clients would trigger this
kind of error. The warning are logged to the "api-warning" channel.
Bug: T305973
Change-Id: I11e9e37af93bc3b9414eb77095e7cc0ce821a462
This changes parseBodyData() to treat request content types ending in
"+json" just like normal application/json requests in order to support
media types such as application/json-patch+json which is used by the
Wikibase REST API for patch endpoints.
Change-Id: Ic47f8f115ec403cab0a8fdd7d53edcd18d130537
Note that "post" parameters remain accessible through
getValidatedParams(), while "body" parameters have to be
accessed though getValidatedBody().
This adds a number of tests that ensure that this remains to be the case,
while deprecation warnings are triggered when appropriate.
Code search to check that this is unused in prod: https://codesearch.wmcloud.org/things/?q=SOURCE+*%3D%3E+*%27post%27&files=&excludeFiles=&repos=
Previous reverted incarnation of this: Ia0eedb383e69b
Bug: T362850
Bug: T358560
Depends-On: Id94335b3ec8f0549ff7350d31cb7cfee8feaa012
Change-Id: I88accc52c5faab70b453709b02ed88a8af4bc181
This splits RouteFileModule into two classes, ExtraRoutesModule and
SpecBasedModule.
ExtraRoutesModule has no module prefix and supports
only "flat" route definition files and additional routes from
extension.json.
SpecBasedModule represents a single module defined in a definition
file similar to an OpenAPI spec. The idea is that a full OpenAPI spec
can be generated by filling in any missing information based on
information provided by the Handler implementation. In particular, the
definition of parameters and request body schemas will be generated.
A JSON schema for the new file format is added under docs/rest/.
Support for the intermediate format introduced in Iebcde4645d4 is
removed. It was not included in a release and was not being used outside
core tests.
Bug: T366837
Change-Id: I4ce306b0997f80b78a3d901e38bbfa8445bed604
One more step in gradually replacing uses of ParsoidOutputAccess with
ParserOutputAccess. This is mostly just inlining the code from
ParsoidOutputAccess (which already uses ParserOutputAccess internally)
and then removing dead code.
Change-Id: I87d6568d9dc71bc11f406ea3c31ce86e01667e05
This fixes the handling for the .../rest.php and .../rest.php/ paths.
The handling for the first case (no "/" at the end) is hard-coded to
redirect to the second case (with a "/") at the end. The second case
can then be handled by a regular route definition.
Change-Id: I9782b17e524f96d7dff4a8e2524fce4ed0940379
The validateBody method in validator is based on BodyValidator.
Returning a non-null value from it triggers b/c behavior in
Handler::validate. That should generally be avoided.
Change-Id: I3047cb0b6fdd8ed623b43910e737d8882f333ff6
When a "pretty" RestPath is configured for outside requests, we still
need the "ugly" path to work for backwards compatibility and internal
requests.
For example, the REST API could be available through /api/ as
well as /w/rest.php. This is equivalent to supporting page views
at /wiki/ as well as /w/index.php.
We can already set RestPath to /api, but then requests to /w/rest.php would fail. We need a way to support both at once.
Change-Id: I9ff8e7345e88b1a4235b6870ec04a87527ed271f
In Iebcde4645d472d2 I broke the way we generate metrics keys from
endpoint paths. Instead of using the declared paths with placeholders,
we were recording the actual paths, resulting in an explosion of metrics
keys.
This moves metrics logging from Router into Module, where the declared
path is available. This patch also introduces regression tests for the
issue.
Bug: T365111
Change-Id: I2c9ddfe6e28aaecd313356894f17033e2db59073
- fix test for body validation errors in HandlerTest that was never
called.
- provide additional test cases for body validation failures
- provide an error key and failure code when encountering extra body
parameters, for consistency with other validation errors.
Bug: T305973
Change-Id: I3453a37f9b5dd1348890046582fb2d25c00dfa6c
REST handlers should explicitly list content types they support for
request bodies. This is needed for generating OpenAPI specs.
NOTE: this removes default support for form data requests, unless
there are "post" parameters declared. "body" parameters require JSON.
Bug: T362850
Change-Id: I1339b1a1770719bd4a5d4d414a8e55fcbb498ac1
I don't think these do anything with the documentation generators
we currently use. Especially not in tests. How are tests part of a
"package" when the code is not?
Note how most of these are simply identical to the namespace. They
are most probably auto-generated by some IDEs but don't actually
mean anything.
Change-Id: I771b5f2041a8e3b077865c79cbebddbe028543d1
Modules group together endpoints by a shared prefix. The idea is that each module has its own version and can generated self-contained self-documentation. This allows clients to have clear expectations about the endpoints of each module, no matter what wiki they are accessing. So far, each wiki may be exposing a different set of endpoints, with no way to provide a spec that describes that set of endpoints in a way that would be consistent across wikis and stable over time.
Bug: T362480
Change-Id: Iebcde4645d472d27eee5a30adb6eee12cc7d046b
Since we introduced support for the "body" PARAM_SOURCE in
getParamSettings, fields in the request body can be defined in the same
way that path and query parameters are defined. However, body fields are
treated separately by the framework, and the value of body fields are
available through getValidatedBody(), rather than getValidatedParams().
Because of that, it makes sense to have a method that returns the param
settings just for the body fields. This also allows handler classes to
override this method separately to specify body fields. That way, it
also becomes possible to have body fields that have the same name as
other parameters.
Bug: T362850
Change-Id: Ia85bf7e46c949a999052d91f1b0d7d579a880108
- fix type on the "rest-body-validation-error" message key, causing
the message to remain untranslated.
- fix error meta-data included when reporting body validation failures.
Bug: T358560
Change-Id: I56ef63e3534770c777cb5f938e3032101abae54b
This change implements two things that can be combined to allow
the usage of services like the TitleFactory in subclasses of
MediaWikiUnitTestCase:
1) This adds getServiceContainer() to the MediaWikiUnitTestCase base
class, to mirror the method of the same name on
MediaWikiIntegrationtest case, along with a a setService() method
for defining service objects for use in tests.
2) This adds makeMockTitleFactory() to the MockTitleTrait, to allow
tests to esaily define the TitleFactory service.
Making services available through a service container primarily
benefits code that relies on ObjectFactory, like REST handlers.
Needed-By: Iac113a9e766e38b2d19ae99b7e448548a515469e
Change-Id: Ida6c37c7133b9e3887268025daf6e5b7c1340e52
