ResponseFactory::createFromException already had support for arbitrary
exceptions, but Router was so far only using it for HttpExceptions,
leaving other kinds of exceptions uncaught.
In addition to catching all exceptions and generating an appropriate
JSON response for them, this patch introduces the ErrorReporter
interface, with an MWErrorReporter implementation which calls
MWExceptionHandler::rollbackMasterChangesAndLog(). This is how uncaught
errors are handled for requests coming in via api.php, so it seems
appropriate to use the same approach for requests coming in via
rest.php.
Bug: T285984
Change-Id: I0605a7693821ef58fac80ab67f51a742556a37fd
Previously, when a user with correct permissions uses completion search on a
private wiki, the results are returned and cached. Since we are on a private wiki,
we don't want to cache results since the content is not accessible to all users.
Now, content that is not accessible to all users will not be cached.
This patch achieves this by setting the appropriate Cache-Control response headers
for the MW REST Search endpoint.
Bug: T292763
Change-Id: I693b4088df9c0520d5238c286312ec52ab273604
By analogy with slow-parse.log. Also, I fixed the log message so that it
has the full title in it.
Change-Id: Icaeb6f002c5c2a676467d4c760f99cb2676ad73b
Migrate away from the Title object, use
TitleParser::parseTitle() which returns a
TitleValue which is enough. Will be followed by
switching UserDefTest to a unit test, but in a separate
commit.
Change-Id: Ia756964861c4e0f3edea89f6beec2643243ca741
Maintain the existing behavior for creating based on a user
id or name that does not correspond to an existing user:
* if creating a User object based on the id 0, User::loadFromId()
will load the defaults with the name being set to false, and
User::getName() will convert that false to the ip of the current
request. We probably don't want UserDef to be doing that, but
this behavior should be changed separately - at the moment
we are just matching the existing behavior (see the prior commit
which adds tests to confirm the behavior isn't changing)
* if creating a User object based on an id that cannot be found
in the database, User::loadFromDatabase() will load the same
defaults, *except* that it will set the user name to "Unknown user"
* if creating a User object based on a name, User::getId() will,
if the id isn't already known, return 0 if the name matches
UserNameUtils::isIP() or ExternalUserNames::isExternal(). However,
the User object is currently only created based on a name after
passing an ExternalUserNames check, and the creation with
RIGOR_VALID prevents it from being an ip. Thus, the existing
code will call User::load(), which will check the database or
fallback to 0 if the user does not exist.
When creating a User from an id that does not exist, User::getId()
will return that id, until after the object tries to fully load,
after which it'll return 0 for the id. Since we cannot replicate
this with UserIdentity (switching the id to 0 only after getName()
is called for the first time) we set the id to always be 0, which
is more accurate. This is the only change in behavior.
We will remove the use of the context ip in a follow-up that will
switch to using "Unknown user" instead.
Accordingly, we will use a UserIdentityLookup as well as
manual construction of UserIdentityValue objects to match this
behavior.
Bug: T288311
Change-Id: Ida80c5d04d721fafa8d66f656dbd346c6cf643eb
This helps phan to detect unreachable code and also impossible types
after the functions.
It helps phan to avoid false positives for array keys
when the keys are checked before
Bug: T240141
Change-Id: I895f70e82b3053a46cd44135b15437e6f82a07b2
Most of the time this is due to garbage user input, and MediaWiki's
normal handling of user input strings is to normalize them, not to
throw.
There are some hypothetical cases where a developer might want to see an
exception, rather than passing garbage to the client and letting the
client fail, but normalization is a defensible policy and works within
the existing interfaces.
Bug: T289597
Change-Id: Ida5ee72c10d1c3499b5b17594c5675db7cd38335
Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59f. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
Updates for the removal of the Revision class itself
and the various methods/hooks/variables removed in the
process, including:
- Update some documentation removing most references
to the Revision class and updating the MCR migration
notes to reflect the past tense for Revision methods.
- Change some capitalization from "Revision" to "revision"
to make it clear comments are about revisions in general,
not the Revision class in particular.
- Minor code tweaks including removing unused variables that
were around for the old hooks that were removed, and
removing the use of DeprecatablePropertyArray where no
longer needed for anything.
- Fix incorrect documentation for PageUpdater::getStatus(),
the status value changed a while ago to have revision-record
in addition to revision, and recently to only have the
revision-record, but ironically PageUpdater was never updated.
- Removed Parser::$mRevisionObject, used to be a Revision object
and was deprecated in 1.35, missed earlier because it was no
longer being set to Revision objects, always null.
- Add RevisionRecord typehints in DummyLinker to match those
in the corresponding Linker methods
This should be a no-op in terms of functionality.
Bug: T247143
Change-Id: I03bbb94fc29085855448780b1a5ad9063911ecc4
It has MediaWikiServices as a parameter, and should be reworked
at some point, so make sure no external callers get added (there
currently are none). Added to release notes as a breaking change
made without deprecation.
Change-Id: I025e5386f414e9c71e2af3fd2f63d25da3125a22
In a few places where a PermissionManager is used
but only GroupPermissionsLookup is needed
Also update references to the class in PermissionManager
that referred to it as GroupPermissionLookup
Change-Id: I5d7a13900852a38768a106aeee1ce012c3a04ea2
In all these cases the property is unconditionally set in
the constructor. The extra initialisation is effectively
dead code and an extra source of errors and confusion.
Change-Id: Icae13390d5ca5c14e2754f3be4eb956dd7f54ac4
SearchResultPageIdentity and SearchResultPageIdentityValue were
introduced as placeholders for PageIdentity and PageIdentityValues.
They can now become aliases.
Bug: T282091
Depends-On: I9b1ab02e0acf12ace107361ea2c443aa543c4880
Depends-On: Ie405ea9539cd18e15b0abb6db6df64ec0135825d
Change-Id: I6eb55c78a0a72be66814f8bc854ba663e7c6f62b
The response from a null-edit should contain the current revision's
revision ID and timestamp, not the info from the edit's base revision.
Bug: T277601
Change-Id: I9d353cdc4cb9e3c1435c93ffe63ef4fef173ec4d
We started to call Authority argument $performer everywhere,
and $performer->getPerformer() doesn't look that good.
Change-Id: Id2cf3f27b18340314e4ed1ea9931ad9404b4df6f
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
This is a follow up to T93097, which worked around a limitation of
SQLite 3.8+ which prevents it from upgrading a read transaction to a write
transaction. Our heuristic is that HTTP POST requests are going to
eventually become DB writes, and so we take the SQLite lock early.
However, Parsoid POST requests don't have any side effects on the DB,
and taking the write lock causes deadlocks during VE saves: the POST
to action=visualeditoredit conflicts with the POST to the recursive
request to the Parsoid REST API. We can't use a GET request for
these requests without hitting query-length limits.
This patch allows REST API calls to set the `X-MediaWiki-Read` header
to opt-out of the SQLite obligatory lock. This avoids the deadlock,
while still allowing the API call to use a POST and avoid query length
limits.
Bug: T259685
Change-Id: If37dc890a24a45c3a914e310b5b5bf625965e9e6
