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
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
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
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
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
- 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
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
Path parameters cannot be optional in OpenAPI specs: each route has a
fixed set of parameters. But the same REST handler can be used for
multiple routes, with some routes using certain parameters, while others
don't.
So from the handler's perspective, these parameters are optional. That
works fine, until we try to generate an OpenAPI spec from the parameter
definitions that the handler returns from getParamSettings. At that
point, we need to inspect the route that the handler was instantiated
for, to see which parameters are actually used in the path. Any
parameters not used in the path need to be excluded from the generated
spec.
Bug: T359652
Change-Id: I81d2c919c87727614a29f53e1dea498326928ef4
This patch uses the recommended MW practice for injecting
settings into MW services. Instead of passing in the full
config object, pass in service options which MW service wiring
will use to lookup settings/options from config sources.
So in this patch, the various options have been identified
and put into `CONSTRUCTOR_OPTIONS` constant and inject via
service wiring.
Test plan
=========
Ensure that the special page: `Special:Search` still works
with this patch checkout on your local test wiki.
When you visit `Special:Search` on your local wiki, you should
see a search form view. Type in something like: "Main Page" and
then hit search. If everything works well, then local test passes.
NOTE
====
This patch also resolves a TODO which mentions the removal of
the `getConfig()` method from the SearchEngineConfig class.
Change-Id: Ib5dfc10f3f210c6c35247f4f30f9549dd60e0af7
Note that "post" parameters remain accessible through
getValidatedParams(), while "body" parameters have to be
accessed though getValidatedBody().
This adds a numebr of tests that ensure that this remains to be the case, while deprecation warnings are triggered when appropriate.
Bug: T358560
Change-Id: Ia0eedb383e69b48a0baa0895a8c9d2229f670367
Throw if a client sends unexpected body fields to a handler that supports body validation.
Bug: T360434
Change-Id: I7b8ed5fe23613183f941ab3b162e0a3c488167df
Since we are now using the parameter validation mechanism also for
fields in the request body, we need to wrap the validation errors to
make clear that the "parameters" are actually fields on the request
body.
Bug: T358850
Change-Id: I02e59a66459e8d88d1c5d0e454da9139ec1b42c6
ObjectCache is already doing a lot of factory pattern logic like
creating instances of the various BagOStuff, this should really be
the responsibility of the factory servicet.
This patch introduces a proper factory (ObjectCacheFactory) to handle
the responsibility of creating various instances of BagOStuff. Since
`newFromParams()` is a static function that gets passed in configuration
of $wgObjectCaches, that can stay that way (to keep supporting how we do
this in prod today).
Technical Breaking Change: `ObjectCache::makeLocalServerCache()` now has
a parameter and requires it but there are no callers of this method outside
MW core hence it is safe to change (and this patch update all callers) to
work correctly. Cache prefix is gotten from global state because sometimes
at this stage, the services container is not available.
Bug: T358346
Change-Id: I3179a387486377c6a575d173f39f82870c49c321
All POST requests must have a body, even if the body's is
empty, with content-length set to 0. When the body is empty, it should
not be necessary to specify a content-type either.
A typical use case would be some kind of "touch" semantics that would
update a resource's state without needing any additional information
from the client.
Change-Id: I7d20bb6a8c484b9b4725f056342ff8d015a171ac
These four endpoints have been experimental for many months:
/coredev/v0/me/contributions
/coredev/v0/user/{user}/contributions
/coredev/v0/me/contributions/count
/coredev/v0/user/{user}/contributions/count
Analytics data shows they are not receiving any traffic.
Remove to clear out the coreDevelopmentRoutes.json file for
unrelated experiments, and to reduce future code maintenance.
Bug: T305506
Change-Id: I21cf9a398638d34725a3c34d348fbad50df40153
This allows HtmlOutputRendererHelper to function for all kinds of
content.
Bug: T311728
Bug: T311648
Bug: T359426
Change-Id: Ib32af7cf2a7ad989eb0b13ecca37c857fc9199ec
HandlerTestTrait::initHandler needs to emulate the behavior of Router::setBodyData,
so test cases that provide an unparsed body in a RequestData object
don't break when we migrate handlers away from using BodyValidator.
Bug: T358850
Depends-On: Icebf044dd4668b36bc9ba76f11520b7acc3347c0
Change-Id: Ib64dbfa4b76fd5c1cc575c835f63347581cc6a9d
Adding getParsedBody is intended to make it easier for us to implement proper request body validation. Also, it get us closer to PSR-7.
Bug: T357025
Change-Id: Ib36d22f15f9226f1f088e55bb335d05dbb7a0e6a
