This reverts commit ecf826a2ee.
Reason for revert: need to edit the patch and then it will be GTG in order to finish hard deprecating of User ::getCanonicalName, ::isUsableName, ::isCreatableName
Change-Id: I2f57f56728fcbeada96dc2228f07dc8bcaa5d4f6
This commit was reverted before cause it has changed the initialization order
and broke FlaggedRevs. Now FlaggedRevs issue was addressed, so we can apply
it back.
Bug: T254838
Change-Id: Id29024caf06fcd0d7d4e039aea8142e8131d47a7
When block restrictions are queried from the API, return the name
of the action blocked
Bug: T280566
Change-Id: I2e639864cfcdd3854fd67173b138fe8eb6f877cb
There's still room for improvement - batching users by prefix
can be abstracted into the UserSelectQueryBuilder, but I'll do that
separately. It still references actor_id, but that's because
we still have to explicitly query rev_user_temp, and different
paging will mess up the continuation. After completing actor
migration I think we can order the results differently.
Change-Id: I75ff6081f8ecb9fd0dcdd7bbd8b0c974ae71101c
Replaces calls directly to PermissionManager with calls to
the Authority object available from Context or the
GroupPermissionLookup service.
This patch does not address use of PermissionManager for
blocks.
Deprecations:
- ApiBase::checkUserRightsAny deprecated passing optional
User parameter
- ApiBase::checkTitleUserPermissions deprecated passing
LinkTarget as first parameter, takes PageIdentity instead
Bug: T271462
Bug: T271854
Change-Id: I5d7cac1c28a37e074750c46cda03283980a07fca
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
Accidentally broken by I991809acf.
Also added a test that should hopefully prevent this from accidentally
being broken again.
Bug: T245149
Change-Id: Ia7985397db50efe8af81f643f2a0a89d0ece179e
This will allow constructing API modules that need services.
This overhauls some of the internals of the ApiModuleManager,
but the public interface remains unchanged.
The $class parameter of addModule, (now called $spec)
also allows passing an array with the spec of the module.
Note that this spec requires the attribute 'class' to be present,
even when 'factory' is specified. This is the same as before,
where $class was always required.
In a perfect DI world ObjectFactory would be injected into
ApiMain::__construct and ApiMain would pass that to its instance
of ApiModuleManager, but that is currently not possible, so for now
it is injected in ApiModuleManager by having ApiMain::__construct
call the service locator.
Bug: T222388
Change-Id: Iee04afc27283547dd68d6db93f44ac2e0ebf1258
This API module can be used to get information about all the languages
supported by this MediaWiki installation. Since parts of this
information, such as the fallback chain, are expensive to retrieve if
the localization cache is not populated, we apply continuation if the
request is taking too long (suggested by Anomie in T217239#4994301); we
don’t expect this to happen in Wikimedia production, though.
Bug: T74153
Bug: T220415
Change-Id: Ic66991cd85ed4439a47bfb1412dbe24c23bd9819
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces calls to
Title::userCan() with the new service in API classes.
Bug: T220191
Change-Id: I768d07a520ca6473a4eefb88c9f587657bc74357
I would argue that these comments do not add any information that
would not be there already. Having them adds mental overhead, because
one needs to read both the comment and the next line of code first to
understand they say the exact same. I don't find this helpful, but
more distracting.
Change-Id: I39c98f25225947ebffdcc2fd8f0243e7a6c070d7
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
If someone is both dumb enough to blindly save an API response and to
then execute the resulting file, this can be used to attack their
computer.
We can mitigate this by disallowing PATH_INFO in api.php URLs (because
we don't make any use of them anyway) and by setting a sensible filename
using a Content-Disposition header so the browser won't go guessing at
the filename based on what is in the URL.
Issue reported by: Abdullah Hussam
Bug: T128209
Change-Id: I8526f5cc506c551edb6138d68450b6acea065e93
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
For example file pages from foreign repos, MediaWiki-namespace messages
that haven't been locally customized, and titles manipulated with the
'TitleIsAlwaysKnown' hook.
This allows clients to be able to display such titles as bluelinks
rather than redlinks.
This also has ApiPageSet populate LinkCache to make later checks of
->exists() and ->isKnown() more efficient.
Bug: T141963
Change-Id: Idbdfd2896c0ce9425ededd7cb4b60eda89ba7ef5
Some generators (e.g. generator=recentchanges) in their default mode of
operation are particularly prone to not generating the same result set
on subsequent requests due to intervening activity on the wiki adding
new entries to the start of the list. We can mitigate this effect by
allowing such generators to provide "non-continuation" data to be used
if the generator isn't being continued.
ApiQueryRecentChanges and ApiQueryAllRevisions are updated to set this
new property. Other generators can easily be updated in the same way as
needed.
There isn't anything we can do about generators prone to having entries
added at random positions in the list rather than the beginning,
unfortunately.
Bug: T146176
Change-Id: I8308d6aa2c89fd2a85e74c7dd8a0a2a9ec927490
All deprecated ApiResult methods are removed. These have been deprecated
since 1.24 or 1.25, and the only users remaining in Gerrit are wrapped
in backwards-compatibility checks and so should not be being called.
ApiBase, ApiFormatBase, ApiMain, and ApiQuery methods for generating the
pre-Ib14c00df help text are removed. Nothing has called these for a long
time, and only Flow implemented them in any way. Deprecated methods for
providing the text for such help, such as getDescription(), haven't been
removed yet, though, since some extensions still call some of them.
Change-Id: I3ca7c98174b4a3f6f67f2b023e0f4446637e7a84
Though getOutput() is what first came to mind, I do not particularly
like the name, partly because it is used in many, many places as a
method that returns an OutputPage object.
* Renamed the method to __toString(). This is appropriate because
each instance, at any given time, corresponds to a single string
value (and exceptions cannot occur during this conversion).
* Removed unnecessary variables from ApiQuery and ExportTest. In
these and most other cases, it should no longer be necessary to
call getOutput() explicitly.
Change-Id: Icf202743d1f332f8981338f42eb6e3e5a04abdf1
Specifically, it is not necessary to use output buffering functions
to capture XML generated by the export code because it is already
possible to set the "output sink" object to be used.
* Created a DumpStringOutput class, which appends all output to a
string property rather than printing output immediately.
* Used that class, instead of ob_start() and ob_get_clean(), in
ApiQuery and ExportTest.
Change-Id: I238f5d5ec7fd442c845b25cb59ef81ac3285099f
* Set API response metadata on the AuthenticationRequest metadata so it
is output as an assoc generally.
* Remove the 'image' field in AuthenticationRequest::getFieldInfo()'s
response, since we ended up not using it anywhere.
* Make it so meta=authmanagerinfo can be used on private wikis without
logging in, so action=clientlogin can be used to log in.
** This generalizes the exception for meta=tokens that was added in
I83dafb030.
* ApiAuthManagerInfo needs the "messageformat" parameter.
* ApiAuthManagerInfo shouldn't be publically cached, since the responses
vary depending on session state.
Change-Id: Iea5ddb4ef9febed18f16a7ae8314968026f39148
Changes here are:
* action=login is deprecated for use other than bot passwords
* list=users will indicate if a missing user name is creatable.
* Added action=query&meta=authmanagerinfo
* Added action=clientlogin is to be used to log into the main account
* action=createaccount is changed in a non-BC manner
* Added action=linkaccount
* Added action=unlinkaccount
* Added action=changeauthenticationdata
* Added action=removeauthenticationdata
* Added action=resetpassword
Bug: T110276
Bug: T110747
Bug: T110751
Bug: T32788
Bug: T67857
Bug: T28597
Bug: T76103
Change-Id: I244fa9b1e0623247d6d9fa30990411c6df94a496
The problem is that ApiQuery requires the 'read' right even though
ApiQueryTokens doesn't.
So, we introduce an exception: if action=query gets only meta=tokens
(and optionally rawcontinue and indexpageids, since they don't affect
anything), no other modules and nothing in the ApiPageSet,
ApiQuery::isReadMode() will return false.
Bug: T130112
Change-Id: I83dafb0305ff0cb1fc3bac668b88b5d2022e5880
No more uses found in core or Gerrit extensions for the following methods:
* ApiQuery::getGenerators() was removed (deprecated since 1.21).
* ApiQuery::getModuleType() was removed (deprecated since 1.21).
* ApiQuery::setGeneratorContinue() was removed (deprecated since 1.24).
Change-Id: I1d46adc9ecad598c7d7726a2243bba4f7a04531a
