A crude solution for the acquireTarget() race condition. Use SQL
GET_LOCK() to lock the target from the acquireTarget() call until the
transaction is committed.
Add FOR UPDATE to the acquireTarget() SELECT, otherwise it just sees the
snapshot version of the row and inserts a new row anyway.
Add a test which reliably failed prior to the change.
Reword the ipb-block-not-found message. This is normal for simultaneous
blocks of the same target. Don't contact us. In the API, remap it to
"alreadyblocked".
Bug: T389028
Change-Id: I1fa35bf08d456a93930194786f77df389217ba61
(cherry picked from commit 2b65587e4d92e7f27661e8821b14f74ade939cfa)
The x-restbase-compat header can be used to instruct certrain endpoints
to produce output that is compatible to the output generated by
REStbase. Since the output varies based on the presence of this header,
we need to send add it to the Vary header to avoid cache pollution.
Bug: T374136
Change-Id: I38c75b2d6f26c49f0ebf5660d34b412ca845ec63
The discovery endpoint provides basic information about accessing the
wiki's APIs, as well as a directory of available modules.
Bug: T365753
Change-Id: I161aa68566da91867b650e13c8aadc87cd0c428c
In order to replace certain /api/rest_v1 endpoints, we
need to have something in MediaWiki that generates a compatible
responser. The MediaWiki REST API error format does not match
RESTbase. So the easiest approach seemed to be to
add a compatibility mode, triggered using the x-restbase-compat
header. This can be set via the gateway when rerouting the request.
Bug: T374136
Change-Id: I73934940d367be52941bd27861c248ab5bcfb5d2
In order to replace the /api/rest_v1/page/title/{title} endpoints, we
need to have something in MediaWiki that generates a compatible
responser. The v1/page/{title}/bare and v1/revision/{id}/bare endpoints
are functionally equivalent, so the easiest approach seemed to be to
add a compatibility mode to them. The compatibility mode is triggered
using the x-restbase-compat header, which can be set via the gateway
when routing the request from /api/rest_v1/page/title/.
Bug: T374136
Change-Id: I4af7ff5325660ae30faebb24753b9dc1c3acb2b3
Conventions for extension REST module names, and the associated
versions, are being established. Initial speculation was to use
a period as a separator, but consensus instead was to use a slash.
Modify the content module's paths accordingly.
Change-Id: Iea9e3fda8d274ebd341d9331458d37247a0384e2
T366837 added the ability to group REST endpoints into modules.
This change now introduces the first use of a REST module.
The existing endpoints remain accessible at their original paths,
and mocha tests are run against both old and new paths.
Bug: T370430
Change-Id: I83a5cdbdd359e4d3e5f70dd3930783616b556738
This demonstrates how to use ArrayDef::makeObjectSchema to define a
schema for a complex body field.
The "latest" field in the request body for page PUT requests identifies
the base revision. To allow the base revision info to be looped through
from an earlier GET request, it's nice to allow the "timestamp" field
to be present, even though we don't use it.
I changed the relevant part of Update.js to test that use case specifically.
Bug: T368131
Change-Id: I166396e0dbfc995e5346252ee438c9afe2c808e2
Anonymous editing with temp account creates a new account (temporary),
so the anonymous token are not valid anymore.
This sets a clear state for each test scenario.
Bug: T365647
Change-Id: I41c6d98a107830f7b9dcc90b91cff0a776767195
- Adjust expected user name auto-generated from the first edit
- Anonymous edit count updated (there's a new temporary count)
- Temporary edit count updated (anonymous users are temporary)
- Total number of unique editors (each anonymous edit is a different
user)
Bug: T365647
Change-Id: I5eb93d8eda607708ba7b03f5dfba4ed7e272ce5c
Anonymous users (temp accounts) have auto-generated usernames.
This change prevents the assertion test of the username for temporary
accounts, while it still tests everything else in the change record.
Bug: T365647
Change-Id: I406340cd54421ef48fa96da76d58cf3b0b8b77e1
Why:
- The tests in this file aren't specifically about anonymous editing,
and using a named user for the test edits makes it easier to support
this test in both a temp accounts and non-temp-accounts context
What:
- Switch the actor used in making edits for the fixtures in the tests to
be a named user
Bug: T365647
Change-Id: Ic3cc846892b03a9a550f39a92686ae904cfa2c82
Why:
- There's nothing in these tests making assertions about anonymous
editing behavior, and using the anon user is problematic with temp
accounts enabled, because after the initial edit, the user is
logged-in, and subsequent edits need a new token.
What:
- Switch the actor used in making edits for the fixtures in the tests to
be a named user
Bug: T365647
Change-Id: If1d3cdc46c894242b2c335e3e8bf25063ea5d8b5
Why:
- We need a clear state for each test run, because anonymous editing
with temp accounts results in a temporary acocunt being generated, and
the anonymous token is no longer valid.
What:
- Set a new REST client so that we have a clear cookie state before
running a test
Bug: T365647
Change-Id: I79666ff92de090e69d32f1152ba330cf913e64e2
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
Change I5521b7652f (commit 682a19e9f6) increased the number by roughly
one order of magnitude, which leaves me nervous that the tests might
start failing again if enough other tests are run in the same wiki to
let the increased revision IDs exist. Let’s bump it further to make that
much less likely (though not impossible).
1219844647 is an arbitrary large number; my intention in choosing a
random-looking number (rather than, say, 1234567890) is that it’s easier
to search for, both in codesearch and in commit messages, if it should
ever pop up in an error message.
Bug: T366142
Change-Id: I8186d9d46bc2a3f5ec04b38aab5cbe85e609835a
Follows-Up: I5521b7652faca9821fa08a9987a9452a4c555203
The default used to be 'ucs2' when linting but
Ic9b7cc0fcf365e772b7d080d76a065e3fd585f80 stopped setting the offsetType
in the environment options, which changed the output to Parsoid's
default, 'byte'.
For the parsing paths, pagebundles are now post-processed and
non-pagebundles were left as a TODO.
However, for the lint paths, it was always ok to continue setting the
environment option because Parsoid is called directly and doesn't go
through the ParserOutputAccess. The above patch was trying to limit
Parsoid specific options to that.
Bug: T365284
Change-Id: I8389c2f53b399b39a9f1d908a38aecb3abcb15ef
These tests fail for wikis with many revisions, and even in CI when
running after a suite that generates many edits such as Wikibase.
Bug: T366142
Change-Id: I5521b7652faca9821fa08a9987a9452a4c555203
Move open search description endpoint from /w/opensource_desc.php
to /w/rest.php/v1/search.
Bug: T363984
Change-Id: Idb5b0d21adc6152ef77e6d17846b6acc6a904e01
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
According to the dictionary, "per" (or more conventionally "as per")
means "according to". Refer OED "per" sense II.3.a. For example:
"No value was passed, so return null, as per default".
In this sentence, we are not specifying the default, we are referring
to the default. This correct usage of "per default" was used nowhere
in MediaWiki core as far as I can see.
Instead we have "per default" being used to mean "by default", that is,
giving the value to use when no explicit value was specified.
In OED, the phrase "by default" is blessed with its own section just
for computing usage:
"P.1.e. Computing. As an option or setting adopted automatically by a
computer program whenever an alternative is not specified by the user
or programmer. Cf. sense I.7a."
There are highly similar pre-computing usages of the same phrase,
whereas the phrase "per default" is not mentioned.
As a matter of style, I think "per default" should not be used even
when it is strictly correct, since the common incorrect usage makes it
ambiguous and misleading.
Change-Id: Ibcccc65ead864d082677b472b34ff32ff41c60ae
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
999 edits isn't that many, even for a freshly created CI wiki.
Wikibase's e2e test suite started hitting this limit which causes
this test to fail.
Change-Id: I0aff1fcc648780201cb2ad14a1e27aafb3e90774
This reverts commit 890558f1fa.
This restores Id584208d9b67d877606a0add1d71c9b1784cdb1b with some fixes.
Bug: T323786
Bug: T352742
Change-Id: Ib31c451ddd75b06c95a544c8a3d2a64b32264126
This is only enabled in development mode for now.
It's intended as a baseline for further development,
the feature is not ready for production.
Bug: T323786
Change-Id: Id584208d9b67d877606a0add1d71c9b1784cdb1b
Co-authored-by: Atieno <pnjira@wikimedia.org>
Add extra checks on all REST API tests which return sucess data values.
This extra check is used to ensure that an accurate `Content-Type` is
being sent to the client, as an incorrect header can cause consumers
to misinterpret the data returned by the API (particularly JQuery, as
described in T352546).
The check was added only to endpoints which return success data.
Tests that check for 4xx status codes do not have the content type
check.
This is a follow-up to I381f33dd.
Bug: T352546
Change-Id: Ib9316b26035ed699f1e607f96e04da110c0edb32
Mostly this has a bunch of whitespace changes from the
template-curly-spacing and brace-style rules being set
to align with other spacing rules.
Change-Id: I4609c52a4ef426ad1f35fb4bfe447bb08323a8e8
This has been constantly mentioned as buggy and broken and there is no
official version of latin or Arabic (see the ticket for more details).
This can be turned back as an extension if needed by third party users.
Bug: T350684
Bug: T268143
Depends-On: I6180dca2c49b3119751766268acc56087aaf8414
Change-Id: Ifbf3c8954d885daf891f8d9efc11743d898302f0
Request that only specify a title, no revision, should get the page
content directly.
Bug: T350359
Change-Id: Ia461cce0df63c05c6f8f94275f6b94f81323d171
This was missed when fixing a similar issue for core endpoints.
I also deleted some dead code in ParsoidHandler, instead of fixing
it to also generate relative redirects.
Bug: T350219
Bug: T349001
Change-Id: If3fe901723dcae9a22806650a21a79778354d8c5
Make HTTP redirects returned by the REST API use relative
URLs in the Location header. This ensures interoperability with the WMF
service mesh, avoiding issues with internal services trying to resolve
redirects by accessing the canonical external URLs.
Note that relative URLs are allowed in the Location header per RFC 7231,
while the obsolete RFC 2616 required it to be absolute.
Bug: T349001
Change-Id: Ibb38c30eb66aaed14ab3ad01ffc42c348a0d07c8
* This is in service of a followup patch that merges ParsoidOutputAccess
and ParserOutputAccess. We want to eliminate all Parsoid-specific options
that aren't part of ParserOptions and aren't easily supportable via
html2html transforms.
* offsetType conversion relies on Parsoid code that is a bit entangled
with env, siteconfig (and extension configs), page source, etc. It
could all be refactored but once the html2html output transformation
framework lands, we could potentially use that to call Parsoid to do
these transforms by exposing such transforms to the framework.
* In this patch, outputContentVersion that isn't the default major HTML
version is no longer support. It could potentially be supported via the
downgrade functionality in Parsoid in the future, or we might decide
to re-enable multiple outputContentVersion selection in the future
if such a use case arises. But, there are no plans to bump the major
HTML version in the near future while we work on read views.
* Rather than delete associated tests, I've marked them skipped so that
they can re-enabled when this support is added back.
Bug: T347426
Change-Id: Ibede4acd68e944512f6d00763d29c6b1605d67eb
