Fix for r97314: don't log HttpError exceptions to the exception log channel. Do
this by overriding MWException::report() rather than
MWException::reportHTML(), same as every other child class in
Exception.php.
Change-Id: I3fb2b0ca9b0e7c67c210078d1fd90e1430be39df
* Make the HTML error message prettier, with a nice red box and
instructions to modify LocalSettings.php hidden in an HTML comment.
* Show the exception class name, since that's pretty safe.
* Show a random "log ID" to the user, and also send it to the exception
log, to allow easier log correlation.
* Optionally send backtraces to the error log, enabled by default.
Change-Id: Ie92e46032b3d194c4217119567847a38a53be577
* PermissionsError now calls OutputPage::showPermissionsErrorPage() to display the error (this is needed to make the item above work correctly)
* Removed the override of the HTML title in OutputPage::showPermissionsErrorPage() so that it shows "Permission errors - Sitename" instead of simply "Permission errors" for consistency with the other things
* Pass the error array returned by Title::getUserPermissionsErrors() to PermissionsError where available
* Converted direct calls to OutputPage::showPermissionsErrorPage() to throw an PermissionsError error instead
* Added 'action-rollback' message that will be displayed when accessing action=rollback without sufficient rights
* Changed getRestriction() in subclasses of Action to return null when they previously returned 'read' so that user rights can be check with Title::getUserPermissionsErrors()
* Reordered checks to do first user rights, then block (if needed) and finally read only (also if needed) so that users don't think the error is temporary when they both don't have right and the database is locked
This code appears to be trying to output something like 'HTTP/1.1 500 MediaWiki Error', but using $_SERVER['SERVER_PROTOCOL']. And it seems to output it on things that run in phpunit tests.
Seems pretty broken?
Also removed htmlHeader() and htmlFooter() since it has zero callers anywhere.
Not sure why useOutputPage() was checking isArticleRelated(), we should be able do use it with other stuff too
* Encapsulate index.php in wfIndexMain() (similar to r77873)
* Kill $wgArticle check in Exception, not necessary anymore
* Kill $wgArticle in Setup, also not necessary
* Add angry note about $wgArticle to rebuildFileCache.
* Remove note about $wgArticle in Parser since it's dying anyway
* Clean up the ugly adding-then-removing-then-readding HTML <head> and <body> tags in DBConnectionError, deprecates MWException::htmlBodyOnly()
* Also deprecates MWException::htmlHeader(), removes code duplication since MWException::reportHTML() can safely call wfDie() and get an output format appropriate for the entry point
* Copy a couple of HTML headers (Cache-control, Pragma and Content-type) to the wfDie() implementation.
* Fix parsing of the three major entry points (index.php, api.php, load.php) back to PHP 4.4.9. We don't care what happens if you actually try to run these files on old versions, but the entry files need to parse correctly.
* consign /includes/templates/PHP4.php and /includes/templates/NoLocalSettings.php to the fiery pit of hell where they belong.
* Prevent loading of any other files for PHP < 5. WebStart.php was rendered unparseable in PHP 4 by the introduction of try/catch blocks in r85327.
* Die outright with a pretty error message on PHP < 5.2.3 as well as PHP 4. All versions of PHP below that throw parse errors of various sorts.
* Reimplement wfDie() to provide an entry-point-dependent die-with-readable-error-message function (for instance, we want a pretty human-readable page in index.php, something wrapped in CSS/JS /*...*/ comment block in load.php, etc).
* Standardise the appearance of the catastrophic errors thrown at the top of the stack with the ones lower down (exception-within-exception, etc). There isn't really a way to do this without duplication, AFAICT.
Wikis which set $wgServer in their LocalSettings or are in a virtual
host would never be vulnerable.
For sites which show the wiki in the default host, it will depend on how
forgiving is their webserver and php stack for that garbled input, although
some kind of foolable proxy —moreover wrongly caching errors (or the default
output buffering is disabled and something incorrectly sent a previous text)—
would also need to be present in order to make that useful for a
potential attacker.
