Improvement: Show the manual login form on request

[abias]

In #490 where hiding the manual login form was implemented, @slaudel commented:

Just one question, how does the local admin get logged in(, in case something is broken with SSO)? I would like to use this on one instance of our moodle systems, but I need to login via manual login to use my admin account.

@slaudel is right in this point. SSO interfaces can break and if this happens, the login into Moodle is broken completely. But to fix a broken SSO, the admin needs to log in. Since the Moodle login requires the login token (see https://docs.moodle.org/dev/Login_token), an approach where Moodle composes the login form itself is needed, the admin can't just create and submit an ad-hoc login form anywhere.

If we agree that this manual login is only necessary for expert users like admins in emergency cases, there are three obvious solutions:

1. Add some documentation which explains to the admin that he can simply re-enable the local login form by running php admin/cli/cfg.php --name=loginlocalloginenable --component=theme_boost_union --set=yes
2. Add a second login page to Boost Union, for example on /theme/boost_union/login.php. This login page would then provide the standard local login form without any bells and whistles regardless of the loginlocalloginenable setting.
3. Add a URL parameter like /login/index.php?locallogin=1to the normal login page which will show the local login form regardless of the loginlocalloginenable setting.

[christianwolters]

Hi,

quick thoughts on this issue:

• option one (document re-enabling via standard cli/cfg) is really the obivous solution, that keeps any future maintenance away.

• is there a real use case for option two? mabye this would come in handy if you are setting up sso and really want this phase as close to later production? but this would also apply to option three, as you can easily switch back and forth?

Any opinions appreciated here...

[slaudel]

Thanks @abias for splitting this up to a new issue. Yes the first option may be the one with the least hassle. But I think option 2 or 3 maybe the more versatile solution. For us, we are using some local accounts for testing, documentation and administration purposes (not testing in the sense of developing) where we don't want to use our personal SSO accounts. So I would prefer option 2, because a special login page could also be more easily protected (by allowing access only from inside the campus network or special IP addresses) via the webserver/reverse proxy.

[christianwolters]

I would prefer option 2, because a special login page could also be more easily protected (by allowing access only from inside the campus network or special IP addresses) via the webserver/reverse proxy.

Good idea!