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
hphpc has been superseded by hhvm, so support for hphpc is no longer
needed.
* Continue to use Preprocessor_Hash under HipHop since it is still
faster under hhvm
* Keep $wgCompiledFiles for now, so that wikihiero doesn't give an error
before Ic9d1e795 is merged
* Migrate the run-server script and associated configuration file to
hhvm. Enable EnableStaticContentFromDisk since it doesn't seem
ridiculously inefficient at first glance. Run from $IP rather than
$IP/.. since hhvm is apparently not picky about sourcing files from
outside of the current directory.
Change-Id: Ic3e769f1fbad4f7ad26dd819406796fee48c6b45
By PSR2 PHP Standard, the files should ends with exactly one newline.
Some of our files have 2 or more and some other were missing a newline.
Fix almost all occurences of CodeSniffer sniff:
PSR2.Files.EndFileNewline.TooMany
I have not fixed the selenium files, I believe we will drop them.
Change-Id: I89fca8c1786fee94855b7b77bb0f364001ee84b6
Remove a trailing whitespace added by me in dirname( __FILE__ )
clean up and add some comments to the PHP version checks (they
can't use __DIR__ as they have to run in older PHP versions.
Change-Id: I6a7e8cb7dbf384d91dda4d0ecbef7ce588bc3073
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
Tim's concerns (listed at
https://bugzilla.wikimedia.org/show_bug.cgi?id=20814#c6) were:
* Lack of Vary: Origin breaks Squid caching
* Vary: Origin on everything would be disastrous, so add an origin param
* Origin header is space-separated list, wasn't treated as such
This commit:
* Remove CORS code from api.php and reimplement it in ApiMain.php
* Add 'origin' parameter to ApiMain
* If 'origin' parameter doesn't match Origin header, send a 403
* If origin is whitelisted, set CORS headers and set Vary: Origin
* Add https?:// to wildcard matching logic, wasn't there but is needed
CORS now works :) you can test it locally as follows:
Set $wgCrossSiteAJAXdomains[] = '*.wikipedia.org';
Log into MediaWiki on localhost
Go to Wikipedia, open a JS console, and run:
$.ajax( {
'url': 'http://localhost/w/api.php',
'data': {
'action': 'query',
'meta': 'userinfo',
'format': 'json',
'origin': 'https://en.wikipedia.org'
// or whichever domain you're on; must be correct!
},
'xhrFields': {
'withCredentials': true
},
'success': function( data ) {
alert( 'Foreign user ' + data.query.userinfo.name +
' (ID ' + data.query.userinfo.id + ')' );
}
} );
Change-Id: I725ce176866d7c81dd9ad6d7bc4a86b7160f2458
