The same way it does already for non-error output. This makes
it so that doPreOutputCommit() consistently happens between
the staging of output and the actual sending of output.
It is still allowed for code to bypass this, such as for fatal
errors and for handlers that disable OutputPage (like Special:Export).
But for cases where we do want to perform doPreOutputCommit(), it
should be run consistently between staging and sending so that it
can make appropiate decisions based on the current state of
OutputPage.
Previously, the state of OutputPage seen by doPreOutputCommit()
would be the broken/incomplete output of a seemingly succesful
(possibly cacheable) user action, which would then, after
doPreOutputCommit() runs, be completely replaced by $e->report()/
$out->showErrorPage().
This is a prerequisite for being able to reliably send cookie-block
cookies on error pages (next patch).
Bug: T233594
Change-Id: Iaeaf5e55a5868e6be534ddda73f3b56b9d6ef8f0
Follows-up d0439af89f.
If the UserNotLoggedIn class is constructed with an unsupported
message parameter, thrown, and handled by MWExceptionHandler, the
report() method would get called, and it would call the parent,
which stages a full error page and sends it via OutputPage::output.
Due to the missing return statement, it would then still execute
the remaining code, which messes up the internal state of the
already-sent OutputPage object by changing its redirect target
(which will never be used, but might confuse other consumers),
and trying to re-send output() and redirect headers, which will
fail with a warning.
Fixing this is required for T233594 and Iaeaf5e55a586, which allows
ErrorPageError to be "stage only" without ending output. Without
this fix, it would call the parent and do stage-only, but then
the remaining code in this method also work and actually succeed
at sending an invalid message to the user.
To preserve current (accidentally correct) behaviour, this needs
to be fixed first.
Bug: T233594
Bug: T17484
Change-Id: Ic5d73becd889839399a5b425cbbe22a3401acea9
AbortAutoAccount, AbortNewAccount, AbortLogin, LoginUserMigrated,
UserCreateForm, and UserLoginForm are all unused in Wikimedia
production and rare in other extensions.
This also scraps the FakeAuthTemplate and LoginForm classes and
the occasional remainig references thereto.
Bug: T193755
Change-Id: I24d6fa963f402d4311fa00fc11536a37ee3bd31e
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Rewrite authentication-related special pages to use AuthManager.
All the changes mentioned below only take effect when
$wgDisableAuthManager is false.
LoginForm is rewritten to use HTMLForm and split into UserLogin
and CreateAccount; ChangePassword and PasswordReset are rewritten;
ChangeEmail and Preferences are updated. Four new special pages
are added to handle the new capabilities of AuthManager (linked
accounts, secondary authentication providers): LinkAccounts,
UnlinkAccounts, ChangeCredentials, RemoveCredentials.
The old form-based hooks (ChangePasswordForm, UserCreateForm,
UserLoginForm) are deprecated. A new, more generic hook is
available to alter the forms (AuthChangeFormFields);
form changes that involve new fields should be done via
$wgAuthManagerConfig.
UserLoginComplete is limited to web-based login; for more
generic functionality UserLoggedIn can be used instead.
Hooks that assume password-based login (PrefsPasswordAudit,
AbortChangePassword) are removed; the first functionality
is replaced by ChangeAuthenticationDataAudit, the second is
handled by AuthManager. LoginPasswordResetMessage is removed,
the functionality can be recreated via authentication providers.
There are several smaller backwards incompatible changes:
* Adding fields to the login/signup forms by manipulating the
template via the extraInput/extrafields parameters is not
supported anymore. Depending on the authn configuration the
login/signup process might be multistep and it would be
complicated to ensure that extensions can access the data
at the right moment. Instead, you can create an
AuthenticationProvider which can define its own fields and
process them when the authentication is over.
(There is B/C support for a transitional period that works with
the default login form, but might break with configurations that
require multiple steps or redirects.)
* Removed cookie redirect check. This was added in 2003 in 9ead07fe9
for the benefit of bots, but with MediaWiki having an API these days
there is little reason to keep it. Same for the wpSkipCookieCheck
flag (added in 2008 in 29c73e8265).
* Instead of embedding a password field on sensitive special pages
such as ChangeEmail, such pages rely on AuthManager for elevated
security (which typically involves requiring the user to log in again
unless their last login was more than a few minutes ago).
Accordingly, wgRequirePasswordforEmailChange is removed.
* Special:ChangePassword requires login now.
* Special:ResetPassword now sends a separate email to each user when called
with a shared email address.
* the Reason field had a message with 'prefsectiontip' class
which was sorta broken but used in extensions for formatting.
HTMLForm does not support that, so this commit turns it into a help message
which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884
Bug: T110277
Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
Add hook LoginFormValidErrorMessages to allow extensions, to add own valid
error messages to redirect to the login form.
Bug: 71769
Change-Id: I9e996a88e3972f09946726060916a21124de049c
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
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
