The goal is to unify the high level control flow in entry points by
making them use a shared base class. Eventually, this will allow
us to test all aspects of request handling, including response
headers and output buffer handling. That will however require
us to move quite a bit of logic from ApiMain into ApiEntryPoint.
Bug: T354216
Change-Id: I4ea1cbb8b2786c24deade7d5029d95fe0c2abc57
The Hooks class contains deprecated functions and the whole class is
going to get removed, so remove the convenience function and inline the
code.
Bug: T335536
Change-Id: I8ef3468a64a0199996f26ef293543fcacdf2797f
Per docs added in I18767cd809f67b, these don't need normalization
as they are only compared against predefined strings, and besides
are generally entered manually in a form, and even then would not
require the kinds of Unicode chars that have multiple/non-normalized
forms.
In nearby areas to also fix some trivial cases:
* getVal('title') obviously needs normalization.
Use getText() to make this more obvious.
* getVal() compared against simple string literals within the code
obviously don't need normalization (e.g. printable === 'no').
* Change hot code in MediaWiki checking for whether 'diff' or 'oldid'
are set to getCheck (which uses getRawVal) instead of getVal.
As a bonus this means it now handles values like "0" correctly,
which could theoretically have caused bad behaviour before.
Change-Id: Ied721cfdf59c7ba11d1afa6f4cc59ede1381238e
* Unlink the word "Action" in api.php description, which was unhelpfully
being autolinked to the index.php Action baseclass.
* Add links in the first sentence to the primary classes involved in
their handling so that the "Entry points" overview page includes
these links (subsequent sentence/paragraphs require an additional
click).
Change-Id: Ibe882746ea7753d5d4c90a04f6974ea807122d1c
Avoid leaking local variables into the global scope by accident, by
moving the entry point code to a function.
In index.php, document the intentional $mediaWiki global so that
nobody removes it by accident.
Change-Id: Ie1a181ae3ebdda90cd2321f0c1b50e31fb0d586e
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
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
Follow-up bc1f601382, which added a group to load.php, but I forgot
to add api.php to its group.
Also, fix the pre-existing group that thumb.php and thumb_handler.php
were a part of. It looks like the entire "Media" group was not
defined anywhere, so it was ignored by Doxygen. This is now fixed.
Change-Id: Iba487aac5883f66b81f2496a38a3c978d5e6600b
Turn this into a doc group, and let the descriptions come
directly from the files in question. This makes the list easier
to maintain, and alsom means that the overview page becomes
discoverable whenever one is looking at the entry point file
as well. Previously the doc page pointed to the entry points,
but not the other way around. This is also fixed.
Bug: T244294
Change-Id: I891c5a37e17592edc1136d7367949927121c8bc8
* Deprecate WebRequest::checkUrlExtension() and have it always return
true. This reverts the security fixes made for T30235.
* Remove IEUrlExtension. This is a helper for checkUrlExtension() which
is not used in any extensions.
* Remove CSS sanitization code which is specific to IE6. This reverts
the changes made to fix T57332, and related followups. I confirmed
that the relevant test cases do not result in XSS on IE8.
* Remove related tests.
Bug: T232563
Change-Id: I7318ea4a63210252ebc64968691d4f62d79a63e9
Set appropriate headers and flush the output as needed to avoid blocking
the client on post-send updates for the stock apache2 server scenario.
Several cases have bits of header logic to avoid delay:
a) basic GET/POST requests that succeed (e.g. HTTP 2XX)
b) requests that fail with errors (e.g. HTTP 500)
c) If-Modified-Since requests (e.g. HTTP 304)
d) HEAD requests
This last two still block on deferred updates, so schedulePostSendJobs()
does not trigger on them as a form of mitigation. Slow deferred updates
should only trigger on POST anyway (inline and redirect responses are
OK), so this should not be much of a problem.
Deprecate triggerJobs() and implement post-send job runs as a deferred.
This makes it easy to check for the existence of post-send updates by
calling DeferredUpdates::pendingUpdatesCount() after the pre-send stage.
Also, avoid running jobs on requests that had exceptions. Relatedly,
remove $mode option from restInPeace() and doPostOutputShutdown()
Only one caller was using the non-default options.
Bug: T206283
Change-Id: I2dd2b71f1ced0f4ef8b16ff41ffb23bb5b4c7028
I doubt there was ever a good reason for mangling $_GET to add the
title, this was just b/c for the sake of b/c. It was formerly used in
core but that was so long ago that I doubt there was any usage in
extensions at the time. Now there is one usage of $_GET['title'] in an
unmaintained extension, but it was only added in 2017.
Also I added WebRequest::getQueryValuesOnly() which is an interface to
the unmodified $_GET. The motivation is allowing OAuth to work with the
REST API, since OAuth needs an unmangled view of $_GET for signature
generation. The Action API gets around the problem with a special hack
in interpolateTitle(), disabling it for the Action API only.
A review of callers of getQueryValues() suggests that many would
benefit from using getQueryValuesOnly() instead. But I only changed it for
callers in api.php and thumb.php since the effect of the change there is
certainly beneficial, whereas callers under index.php may possibly be using
the path parameters to construct self-links.
Rest\RequestFromGlobals uses $_GET directly, which means that this
change causes it to not return PathRouter matches as GET parameters
anymore.
Change-Id: Ic469577fae17c0b1ac69466df7bc9f03e61c74e3
Define the global constant MW_REST_API in rest.php, by analogy with
MW_API. Also generalize this by adding MW_ENTRY_POINT, which contains
the entry script name, "cli" or "unknown". This allows tests such as
if ( MW_ENTRY_POINT !== 'index' )
which is probably what is really intended by defined('MW_API') in many
cases.
Change-Id: I24099f4cdd170de17afd6e1bbad67c9b204071fc
These two entry points have themselves partly indexed by Doxygen
in a very strange way where these two comments cause part of an
if-statement to be seen as the name of a local variable.
Probably due to some kind of bad interaction with the
maintenance/mwdoc-filter.php filter applied to the file before
it gets indexed.
Fix it for now by avoiding use of /** blocks for something that
isn't a class, function, class member or documented global var.
Change-Id: I4903069e704c3283e6ec7a39999a489d0117cc71
ApiMain (and also api.php) tries to catch any Exception so as to provide
a properly-formatted error message to the client instead of an HTML
error page.
With PHP 7.0, some cases that produce an Exception in HHVM instead
produce an Error. The API code should catch these too.
Fortunately neither Zend PHP nor HHVM care if you try to catch a class
that doesn't exist, so we can just add catch blocks for Throwable and
not worry about it.
Bug: T202416
Change-Id: I189eee466bd09870bc172f2420be393a7c0b1900
The siteinfo API response's 'writeapi' value is now hard-set to true,
as are the ResourceLoader variables wgEnableAPI and wgEnableWriteAPI,
to be deprecated later.
Bug: T115414
Change-Id: I54ff9428b247ba203d67aba079149393f323d5a9
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
The following entry points already didn't have it:
* opensearch.php
* thumb.php
* thumb_handlers.php
Now removed from api.php and load.php as well. The check was broken
because these entry points use the 'use' keyword for PHP namespaces,
which results in a syntax error on PHP < 5.3.
The check remains in index.php, mw-config/index.php, and
Maintenance (for e.g. install.php).
Bug: T112942
Change-Id: I9026d69ddfb3e02612256b4a9df525c432bb33c6
* Added doPreOutputCommit() and doPostOutputShutdown(),
which most entry points just using the later
* Also fixed problem where text profiling did not show up
* Avoid calling triggerJobs() in the file streaming
entry points
Bug: T100127
Bug: T100085
Change-Id: Ibc7e768fd483389a01847f08cdeba4058c853d3f
This way, if someone tries to install MediaWiki via
either web installer or install.php maintenance script,
after obtaining from git, they get some useful information
on what to do.
Put the checks alongside the php version check, as
stuff installed via composer (mustache / lightncandy)
is used for NoLocalSettings.php and install.php
attempts to use logging stuff.
Also tried to make PHPVersionError look slightly nicer,
with some <h2> elements and more padding for the <p>
elements.
and centralized this code in one place, as much as possible,
for improved ease of maintenance.
Bug: T90438
Bug: T88951
Change-Id: Iae4eb42c4266dbe9213c5de8a96fccfbeaa9acb0
Seriously, the ops team spent some time trying to find that page during an outage,
while in fact it's an obscure Tolkien reference - better be clear.
Also, set the other dummy titles to something very clearly explaining what's
going on and where.
Change-Id: I6f33a2ea5030f22a258830a33f7bcefa7f0acd85
Move the MWLogger PSR-3 logging related classes into the
MediaWiki\Logger namespace. Create shim classes to ease migration of
existing MWLoggerFactory usage to the namespaced classes.
Bug: T93406
Change-Id: I359cc81fbd2dcf8937742311dcc7d3dee08747b0
We set $wgTitle to a dummy title, and RequestContext::getMain()->getTitle()
falls back to that so everything *works*, but RequestContext whines
about it.
Set the same dummy title explicitly on RequestContext::getMain() to shut
things up.
Bug: T78414
Change-Id: I5b90df16cf2f51a6edd5898e9712161f335202a7
When a logging service other than MWLoggerLegacySpi is used, the
behavior of wfErrorLog is not guaranteed.
Change-Id: I8543bfd556aa752665f7a3daa855d3c2f7fc8956
If the User language is accessed from ApiMain::__construct on a request
via OAuth and the authorization headers weren't valid, the
UsageException was not being handled.
Further, the code setting $wgLang in that constructor should be using
the language just set on the local context, not the main request
context.
Bug: 72384
Change-Id: I90900dc4a8aea22c67c0c05b38128d5dbb044f07
The execution of an API request can throw an exception.
In those cases $processor->getModule() could return NULL.
Use the module manager directly to try to retrieve the
module instance.
Change-Id: Ie49762681ef797388216ab40d99b8e7458a837f6
api.php was directly accessing $_SERVER superglobal.
It should use WebRequest wrapper object instead.
Change-Id: I244fb7a35476e9a35a5dc97f898d39c82c54b7fa
* Harmonize spacing
* Use // for comments rather than #
* Harmonize call style for 'require', 'include' etc.
* Add missing profileinfo.php5
* Use "./" for path to api.php in api.php5 (to match other php5 files).
* Move documentation related to Setup.php from index.php to WebStart.php
* Remove "Initialise common code." comment in api.php (was already remove
in most entry points)
Change-Id: I8dc4a79fd13cee49e34f250a4039b3666bd42aca
The immediate impetus behind this change is this series of events:
1. CirrusSearch hooks ApiBeforeMain to handle some setup that requires
the User object.
2. So User is loaded from the session.
3. OAuth checks the headers as part of loading User.
4. OAuth sees that the headers are invalid, and since it was called from
the API it throws a UsageException, expecting the API to catch it and
return an appropriate response to the client.
5. But nothing does so, leading to an unhelpful "Internal Error" page
being returned to the client.
We can do better than that.
Bug: 62312
Change-Id: Ib5735661eec6ebe57eaa69c67b399e703cc90fc4
When using PHP-FPM to run PHP on a web server, the function
fastcgi_finish_request is provided, which flushes all response
data to the client and closes the connection, allowing PHP
to perform additional work without delaying the client.
This adds fastcgi_finish_request calls in index.php and api.php
where appropriate and if the function exists, so that the connection
is closed once the output is definitely finished.
Change-Id: Ic67a8956545874e94df5198088c0f4aa58ca376e
$wgExtensionFunctions is called before the RequestContext is really
available (i.e. getTitle() is null, accessing the User object may fail
because other extensions' UserLoadFromSession hooks don't expect to be
called that early, etc). The index.php code path has BeforeInitialize to
take action after RequestContext is available but before much else
happens, but the API doesn't (yet) have anything similar.
Bug: 58380
Change-Id: I0a167faaa4166da381194c53373d82e038848924
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
