This changes the current:
> Internal error.
To be:
> [89466ede] 2015-09-23 16:40: Fatal exception of type Less_Exception
This matches how exceptions are reported on HTML pages by MediaWiki
(via MWException::getHTML in OutputPage).
The IDs are okay to be public and exposed on HTML pages even when
$wgShowExceptionDetails is disabled.
Follows-up d478ffde10. Ref T110659.
Change-Id: I501eaa629161184ba89d44e53cdac20b39cb0903
Make MediaWiki\Logger\LegacyLogger and
MediaWiki\Logger\Monolog\LineFormatter better at outputting stacktrace
information and provide support for 'exception' data in the logging
context that is a structured array in addition to the default Exception
object support. This works with MWExceptionHandler::handleFatalError
generated data that is provided by an HHVM interpreter and cannot be
delivered as an Exception class.
With this patch, a good value for LineFormatter's format would be:
"%datetime% %extra.host% %extra.wiki% %channel% %level_name%: %message%
%context% %exception%\n"
Bug: T89169
Bug: T107440
Change-Id: Ida01ed51c573e1654346e716723e543a1be63090
Split fatal error handling out of MWExceptionHandler::handleError() and
move to MWExceptionHandler::handleFatalError() which has been updated to
work as a dual purpose error handler and shutdown function. Under HHVM
it will be called as an error handler and receive a stacktrace via an
undocumented extension of the error handler callback data. Under PHP5 it
will be called as a shutdown handler and attempt to gather data via
error_get_last().
Also update the error handler installed by Hooks::run() to delegate to
MWExceptionHandler::handleError() for most errors. This will allow us to
properly handle errors raised from within hooks.
Bug: T89169
Change-Id: I0f1c66f203b91fff9069520169ecc4a3b55c43d0
* $wgLogExceptionBacktrace from MWExceptionHandler
unused since 77a397125f
* $wgPasswordPolicy from WebInstallerName
unused since 6a69a4eb73
Change-Id: Ibaac1bad05f4326a2602958a93d4d46135bdca63
Replace wfDebugLog() calls in MWExceptionHandler with direct use of
LoggerFactory and LoggerInterface. Logged exceptions are added to the
log message context.
LegacyLogger is also updated to append stack traces to any log event
when $wgLogExceptionBacktrace is true and the PSR-3 recommendation of
passing the exception as an 'exception' context item.
Handling of context data in LegacyLogger is expanded to support arrays,
exceptions and common object types.
Bug: T88649
Change-Id: I71499d895582bdea033a2516c902e23e38084080
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
Also:
* Update wfHttpError() to use uppercase DOCTYPE, to match other code
such as Html.php, wfThumbError(), HttpError.php, etc.
Change-Id: I4027e7fe1a138b03f78797b6d1bfe7bd1064d360
This is the only case in the MediaWiki code base where a custom
message is used. Supporting in the standard HttpStatus library
would require a $customMessage parameter which seems unnecessary.
Additional information should be communicated using additional
HTTP response headers or inside the body content.
Besides, in current PHP versions and in Apache 2.4, the message is
already being ignored and replaced with the standard message (see T100984).
Bug: T100984
Change-Id: I11b58a2f3ce22568479d36027d15e5c6f428ff15
Wasn't actually a vulnerability because HttpStatus::getMessage
can only return one of a fixed set of values which are all plain
text without any special characters. However the return value
there is meant to plain text and not html, so just like
Html::element and other interfaces, things should be consitently
escaped.
Also renamed variables for clarity.
Change-Id: I8b61d7e9ea4101e3a9ef5f9a59a97db45aeef68c
There's no reason for $ex->getMessage() to return nothing. Do like
ErrorPageError does and get the default English message for the parent.
Also move the appending of $titleText to $errorMessageParameters into
MalformedTitleException itself and document it, so every catcher of the
exception doesn't need to know about this, and fix the check so it
doesn't screw up for title "0".
Change-Id: I43d988602b847b67a3cf0aa84e271a0b5bd9adae
includes/Title.php
* The private method Title::secureAndSplit() now throws a
MalformedTitleException instead of returning false on invalid
titles.
* Added Title::newFromTextThrow(), which behaves exactly like
Title::newFromText() but throws MalformedTitleException instead of
returning null on invalid titles.
includes/title/MediaWikiTitleCodec.php
* Provide more information with the thrown MalformedTitleExceptions.
includes/MediaWiki.php
* Use the new Title::newFromTextThrow() to get detailed error
information, display it.
Change-Id: I4da8ecb457a77473e32d745ba48ab8505b35e45f
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
This makes sure static analyzers don't warn for supposedly unsafe
code accessing variables as strings when they could be boolean after
having only checked against false.
https://github.com/scrutinizer-ci/php-analyzer/issues/605
Change-Id: Idb676de7587f1eccb46c12de0131bea4489a0785
* Do not bother with profiling data, which is just another
thing that can go wrong.
* Catch DB rollback errors to avoid getting stuck in
report() loops during network partitions.
Change-Id: I92293b2261c48cf49625ea14a51987e5619ab8d4
'error' is currently disabled in Wikimedia production, but we still need
to log stack traces for fatals.
Bug: T89169
Change-Id: Id0255651f228037152b87022f5eb696c1050b9ec
These errors usually need to be reported, so it's better for the user
to understand them as much as possible.
Bug: T40095
Change-Id: Ibd2f984b66acb9150400126f21acf7cc5fc85acd
MWExceptionHandler::handleFatalError() is installed as a shutdown
function to inspect `error_get_last()` output and log the error via
MWExceptionHandler::logError(). The error is examined to determine if it
is a missing class error so that a descriptive log message can be
provided instructing the server administrator on 3rd party library
installation methods.
Bug: T74777
Change-Id: I04748626487022c51050ffa7846236947a082d68
Follows-up 399ba2fecf which didn't include any translation of the error
type in the logged message (e.g. "PHP Notice" or "PHP Warning").
Before
Error from line 2130 of mediawiki/includes/OutputPage.php: Undefined variable: bar
Error from line 2130 of mediawiki/includes/OutputPage.php: strpos() expects at le..
After
Error from line 2130 of mediawiki/includes/OutputPage.php: PHP Notice: Undefined variable: bar
Error from line 2130 of mediawiki/includes/OutputPage.php: PHP Warning: strpos() expects at le..
Based on the log formatter in php
https://github.com/php/php-src/blob/0f5858e3a328/main/main.c#L1086-L1119
Change-Id: I52f98e52caa64955050ed73e1acbc78b1116a9fd
* Remove use of 'error' where it's redundant.
* Remove call to logException from responsibility of MWException.
Call from exception handler instead.
Change-Id: I8764cf5df87b226813c9b9cf99f9b4f3fa4b7c92
Add hook LoginFormValidErrorMessages to allow extensions, to add own valid
error messages to redirect to the login form.
Bug: 71769
Change-Id: I9e996a88e3972f09946726060916a21124de049c
Previously, non-MediaWiki exceptions were logged only for api requests,
job runner, resource loader, etc. but not for general requests
such as page views.
Bug: 61914
Change-Id: Id4de5cac0b9996a98cdaf5e73655d49fa55ea8c3
The replace of $n params can also be done using the Message class. In
case there are no message keys, the RawMessage class is used.
Deprecated wfMsgReplaceArgs, but added no warning, because it is used in
some extensions and from deprecated functions
Change-Id: I62091b09e4490e59ed7258566e0ddf2f8ee799d2
For pages like Special:Watchlist that throw
a UserNotLoggedIn exception when the user is
anonymous, this patch makes the page redirect
to the login page automatically.
This is instead
of the current behavior of showing a link to
the login page that the user must click.
(Also, Special:Userlogin has existing functionality
that will redirect the user back once they are
logged in.)
Bug: 15484
Change-Id: Idd9325374cb5dc13c4c057f45f88a33bdff523a9
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I41a84e8e1dec39170aa655250325ffc485eaeaef
Lots of small issues that could be very annoying:
* Usability regression: the user is not informed *why* they were
redirected to the login screen. Not even a generic "You must log in
to complete this action".
* When testing this on my watchlist, after logging in I am now redirected
to http://localhost/wiki/index.php?title=Watchlist&title=Special%3AWatchlist
(the title is repeated twice and one of them is incorrect). This
worked correctly before.
* SpecialPage::requireLogin() needs documentation and code updates.
* A whole ton of messages used in these prompts is now unused.
* Probably needs release notes.
I don't have the time to fix up myself right now, and a WMF
branch cut is looming. Let's just try this again later.
This reverts commit e0af129cbd.
Bug: 15484
Change-Id: I728e477cf6e10b90846ee0b2d9e5087bc3a0af3e
For pages like Special:Watchlist that throw
a UserNotLoggedIn exception when the user is
anonymous, this patch makes the page redirect
to the login page automatically.
This is instead
of the current behavior of showing a link to
the login page that the user must click.
(Also, Special:Userlogin has existing functionality
that will redirect the user back once they are
logged in.)
Bug: 15484
Change-Id: Ic7e1d5a8984e1b42c8f2ebceff094106a3ed1efa
