![]() At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process. You can enable it and move it up and down in the order. You will see your plugin in the list, appearing as ]. Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication".Implement the user_login() function in your auth.php file, and create or override additional functions based on your plugin's requirements.Within the file, create a class auth_plugin_sentry that extends auth_plugin_base from /lib/authlib.php. Create the file /auth/sentry/auth.php.It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc. Under your Moodle installation root, create the directory /auth/sentry.We'll use 'sentry' as an example below change it to whatever name you have chosen. Please see Moodle none authentication plugin (auth/none), it's the perfect plugin template to start with. Google / Facebook / Messenger Oauth2 Authentication plugin Template Note that in this scenario above user_login($username, $password) is never called and should probably return false. If this happens inside pre_loginpage_hook() then the user continues on their way, or if inside loginpage_hook() or another custom page then the plugin should redirect to the wantsurl. The auth plugin now validates the token or decrypts the assertion, does any other checking as required and then logs the user in using complete_user_login($user).The remote authentication service redirects back to moodle with an assertion, such as a single use token or encrypted response in a query param. ![]() ![]() The user enters their credentials and authenticates on the 3rd party page.Or if they go directly to the login page moodle calls loginpage_hook() on each enabled plugin, which may redirect to the 3rd party login page.Access a protected page but isn't logged in, so moodle calls pre_loginpage_hook() on each enabled plugin, which may redirect to the 3rd party login page.Otherwise, it figures out where to send the user based on their original page request, whether their password is expired, etc., and redirects them there.įor the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc): $user is a valid object) and, if not, sends them back to the login page with an error message. Calls authenticate_user_login() in /lib/moodlelib.php, which returns a.Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).Runs loginpage_hook() for each plugin, in case any of them needs to intercept the login request.Gets a list of enabled authentication plugins.The handler code in /login/index.php runs:.A user enters their credentials and submits the form. ![]() OR, if a system administrator has set the Alternate Login URL on the "Manage authentication" page, that URL will be displayed. The default login page ( /login/index.php) is displayed.There are two broad classes of authentication plugins, the regular type where moodle handles the password and ones where the password is handled by a 3rd party page eg SAML, OpenID etc.įor the regular plugins the following happens (skipping some minor details and rarer scenarios): ![]() The authentication use case in Moodle starts when a user clicks on the Login link in the UI or if they try to access a protected page. Overview of Moodle authentication process This page first gives an overview of the authentication process and then explains how authentication modules can be created using hooks to take over from the native authentication in Moodle.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |