Moodle 3.3.highest ... using CustomOauth2 login.
Is there a way to create a login screen that shows only intro (first time here text) with the CustomOauth2 login button generated by Moodle and for admin levels who need manual login form a page/form for those few users?
Thanks in advance,
Ken
Bump?
Did find another user that shared their alt login page for the 'normal' login ... the login/password box one normally sees in a non-altered/non-customoauth2 moodle. But haven't seen a suggestion/page example of a login page that shows *only* the customoauth2 button.
Appreciate any hints/clues/examples.'
'spirit of sharing', Ken
Well, let's try it again ... is there a way to hide (via css) the left panel of the normal login screen such that the Login and Password prompts/data entry boxes, table column, does not appear to the user?
Only the right column (that which normally has the title "is this your first time here?") would be displayed with the 'button' for the customoauth2 login.
'spirit of sharing', Ken
Guess I'll turn this thread into a blog (reference). :\
Making progress ... but first ... an observation ...
The login to these forums has *all* login interaction in/on the left panel of the login screen with 'first time here' info and a button to create an account on the right. Very logical. We all know that as users get accustomed to certain screens they focus their attention where it's needed and basically ignore the rest.
The default login page as built by the software everyone uses once having configured an oauth2 login has the button built on the right (underneath the 'first time here' info.
Wouldn't it make more sense to users if all the login interaction were on the left (like moodle.org)?
Have begun work by cloning auth/oauth2/ and then creating an 'altl' (alternative login) form. Kinda have to do it this way as the link to the oauth2 server is generated by queries to the DB for ID number of the service + there is a session key that is generated ... and built into the link ... as well as a 'wants' parameter.
Have hacked the copy (altl) a little ... changing the requirement line for config.php since altl is not in the auth subdirectory of the original code. And have figured out the URL that goes to the customoauth2 ID server. Un-fortunately, today of all days, the IDM server behind clouldflare is not responding ... get a 522 error from CloudFlare.
Now just need to figure out how to hack a form so that only the Oauth2 button shows ... along with whatever the 'Moodle Masters' want to say on the form.
Oh, yeah ... site was installed by git and is maintained by git ... while this practice might be risky if code for a customoauth2 service changes ... don't want a git pull or an upgrade to code fail due to 'un-known' code present, so am using hidden git ignore file to eliminate the altl directory.
Next posting to this 'saga' might resume Monday?
'spirit of sharing', Ken
Guess I'll close this blog reference.
Ended up creating 2 customized pages for logins ... 1 for the admins of Moodle, and the oher for the IDM users.
#1 works. Still can't test #2 as the IDM system (keycloak) is as the developer phrased it ... 'add-hoc' ... e.g. not up all the time.
Seems we have a little disagreement as to what test needs to be performed when it comes to Moodle. IF I re-call correctly, if, when using the IDM and a user can authenticate via that system, moodle detects that the account already exist as a 'manual' account, user is prompted to 'merge' (think that's what the docs said) the accounts. Thus existing user ID in mdl_user table stays the same and only relate authentication fields change in mdl_user. Do know this, if users are given an option, they sometimes choose in-correctly - especially if not forewarned/educated to the correct choice (last I heard, Google Classroom, prompts the user to choose if they are teacher or a student and a wrong choice there begets un-desirable results). IF the information screen for Moodle offers a choice and user chooses in-correctly, wanted to see what happens to the backend tables related. Seems to me the only fix would be direct manipulation of the DB.
Two other things .... entity is 'expecting' (or has been promised by consultant for IDM) single sign on where the users login to workstation and they won't have to provide credentials to Moodle to access. Kinda interesting as many accounts are not from the corps wide area private network, but from other corps.
Moodle does have task to clean up stale sessions.
And, the consultant dropped a line that might prove to be interesting ... 'directive to put all behind cloudflare'. The 'proof of concept' Moodle (a clone of their production server with different FQDN) is hosted on RackSpace and RS does have a 'partnership' with ClouldFlare. That's all done via DNS from what I read. It's still a factor from time to time ... even Moodle.org access begets that 'Oops! Something is wrong with the Internet'.
That affects direct access ... which, in that case would have to be by IP address .... and there is, of course, the moodle config ... this URL only.
Since it's linux I could still access via ssh to do updates/upgrades via git but might not be able to check if other plugins needed updating/upgrading if 'the internet' is 'down'. OK, don't do updates or upgrades if that's true then. Fine by me!
Anyhoo ... that's all for this blog! ;)
'spirit of sharing', Ken