Open brendanheywood opened 5 months ago
Personally I dislike the UX requiring an email address to be entered before allowing the user to select an IDP -but no objections to having this within the plugin - I suspect in some cases this will mean the users have to enter it twice - once on the intial form, and then again on the idp login itself if they are not already logged in.
It's not for everyone, but for many large institutions its a privacy thing. They must not show user A from domain A that domain B is also a client in the same system. It can still be enumerated but it's much better than showing up front.
In an ideal world we could figure out how to pass the email through into the idp's login form but that's gonna be different for each idp and out of scope here.
With the poor UX of double email entry, this plugin could also implement a simple IdP discovery mechanism where if you have previously logged in via one idp then stash a cookie and don't prompt the second time.
ah - privacy driver makes a bit more sense - I've seen client initiated requests where a special link is stored within a corporate portal that initiates the idp login and redirects back to the LMS but that requires the user to always use the portal link rather than hitting the lms directly.
This is broadly the same as this tracker but done here as a stop gap as it's not clear if its desirable to land in core
https://tracker.moodle.org/browse/MDL-57835
The idea is that:
1) in the config it detects there are N idp's 2) it presents an optional text area for each login method 3) each text area accepts a partial email or domain on each line 4) on the login page, if any idp has anything optional config then an email box is shown at the top 5) if an idp has config then it is not shown by default 6) as the user finishes typing their email address a webservice checks and if it matches any idp's then they are shown 7) if only one matches then it instantly redirects 8) if all login methods have config then only the email input is shown 9) there would be some fallback method so if no idp matches, then for example manual logins are shown 10) in the case of any auth plugin which uses a password instead of an idp then a second password field is shown, including the login token and they continue to login normally 11) when doing the web service check it also matches usernames, looks up the email, and applies the same logic as if the email was entered (maybe behind a setting?)