Page MenuHomePhabricator

Remove the requirement to enter a password during the login flow
Open, Needs TriagePublic

Description

At the moment the login page of MediaWiki, in the default configuration, requires the user to type in their username and their password in order to be able to click the login button (which should be the main confirmation element of this form). This, however, limits the possible authentication credentials to be a set of username and password. It prevents extensions to provide an AuthenticationProvider which adds additional ways to prove the identity of a user, when the extension is based on the username. For example the Passwordless Login extension[1] (done through the Wikimedia-Hackathon-2019) requires the user to type in their username but not the password, as the identity will (in a second UI step) be proved by a second factor (smartphone login prompt).

There may also be other possible login mechanisms, which require the user to type in their username but not their password.

This task does not exactly propose a way to solve it (however I'll post three possible solutions from my point of view) but should be here to discuss how this could be solved, in order to find a suitable solution.

The problem (the required password field) could be solved in these ways, from my point of view:

  1. Removing the "required" attribute from the password field

-> This is probably one of the worst solutions, as there's no clear indication for the user that the field is not requires, when they should fill it out and when not. I would consider this bad UI/UX for the user during the login flow, however, it would be the easiest implementation I think.

  1. The password field is removed from the initial Login form. If the user entered their username, they can just click on "Continue" (not Login anymore) and the AuthManager will check all available PrimaryAuthenticationProviders about their AuthenticationResponse. If multiple providers respond with a new UI, the provider with the highest priority will win (this could also be the PasswordAuthenticationProvider). The user then does whatever the UI says (e.g. type in their password or verify the login on the smartphone) and continues with the login process then. Additionally, if more than one provider answered with a new UI, the user probably sees a list of links where they can switch to another authentication mechanism (e.g. switch from Passwordless Login to the password login).

-> This would be the biggest user-facing change I think. It would completely chnage the login flow, breaks any password manager auto-fill option, if I'm not mistaken, and will require more steps in the login flow for the users. However, I think this would be one of the "cleanest" implementations.

  1. This would be a mixed version of 2. Anything of 2 would be implemented, but behind a feature flag. That means, that the MediaWiki site-admin would need to set a configuration option in order to enable it and they can decide if it does make sense to do so, e.g. when they installed an extension liked Passwordless Login.

Let's discuss about that and probably there're other ideas about how this could be solved, too :)

[1] T220418: Passwordless login (login with your smartphone)

Event Timeline

Florian created this task.May 20 2019, 11:44 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 20 2019, 11:44 AM

I played a bit with the first solution, however, it turns out that, even if we move the password field into a second step (which would mean, that the AbstractPasswordPrimaryAuthenticationProvider needs to return a UI AuthenticationResponse in the beginPrimaryAuthentication step), there's the problem thet AuthManager requires a response from continuePrimaryAuthentication to be non-ABSTAIN (which makes kind of sense). However, this means, that there can only be one password authentication provider listening for the second, new, UI step, however, core ships with 2 already (temporary and local passwords).

So, question into the round: What are the problems with making an ABSTAIN response valid in a continue authentication step?