Authentication plugins - Revision history

Mudrd8mz: Text replacement - "`" to ""`


2021-07-14T13:09:04Z
Text replacement - "<code>" to "<syntaxhighlight lang="php">"

				
				
				
				
				
				← Older revision
				Revision as of 13:09, 14 July 2021
				
Line 13:
Line 13:
## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request. ## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request.
## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed). ## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).
## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <code>$user</syntaxhighlight> object. (Details of this code follow this main outline.) ## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <syntaxhighlight lang="php">$user</syntaxhighlight> object. (Details of this code follow this main outline.)
## Determines whether authentication was successful (by checking whether <code>$user</syntaxhighlight> is a valid object) and, if not, sends them back to the login page with an error message. 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. ## Determines whether authentication was successful (by checking whether <syntaxhighlight lang="php">$user</syntaxhighlight> is a valid object) and, if not, sends them back to the login page with an error message. 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.



For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc): For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):
Line 37:
Line 37:
# Choose a name for your plugin.  We'll use 'sentry' as an example below; change it to whatever name you have chosen. # Choose a name for your plugin.  We'll use 'sentry' as an example below; change it to whatever name you have chosen.
# Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>.  It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc. # Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>.  It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.
# Create the file <tt>/auth/sentry/auth.php</tt>.  Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>.  (You will need to <code>require_once</syntaxhighlight> the authlib file.) # Create the file <tt>/auth/sentry/auth.php</tt>.  Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>.  (You will need to <syntaxhighlight lang="php">require_once</syntaxhighlight> the authlib file.)
# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements. # Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.
# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication".  You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>.  You can enable it and move it up and down in the order.  '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.''' # Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication".  You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>.  You can enable it and move it up and down in the order.  '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''

`Mudrd8mz: Text replacement - "`" to ""

2021-07-14T13:05:34Z

Text replacement - "</code>" to "</syntaxhighlight>"

← Older revision		Revision as of 13:05, 14 July 2021
Line 13:		Line 13:
	## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request.		## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request.
	## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).		## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).
	## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <code>$user</~~code~~> object. (Details of this code follow this main outline.)		## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <code>$user</syntaxhighlight> object. (Details of this code follow this main outline.)
	## Determines whether authentication was successful (by checking whether <code>$user</~~code~~> is a valid object) and, if not, sends them back to the login page with an error message. 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.		## Determines whether authentication was successful (by checking whether <code>$user</syntaxhighlight> is a valid object) and, if not, sends them back to the login page with an error message. 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.

	For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):		For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):
Line 37:		Line 37:
	# Choose a name for your plugin. We'll use 'sentry' as an example below; change it to whatever name you have chosen.		# Choose a name for your plugin. We'll use 'sentry' as an example below; change it to whatever name you have chosen.
	# Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>. It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.		# Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>. It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.
	# Create the file <tt>/auth/sentry/auth.php</tt>. Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>. (You will need to <code>require_once</~~code~~> the authlib file.)		# Create the file <tt>/auth/sentry/auth.php</tt>. Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>. (You will need to <code>require_once</syntaxhighlight> the authlib file.)
	# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.		# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.
	# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''		# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''

Jeferod83: /* Interfacing to API's */

2019-05-24T19:17:38Z

Interfacing to API's

← Older revision		Revision as of 19:17, 24 May 2019
Line 85:		Line 85:
	; '''Return type''' : boolean		; '''Return type''' : boolean
	; '''Default return value''' : true		; '''Default return value''' : true

			=== <tt>is_configured()</tt>===
			Returns false if this plugin is enabled but not configured.

			; '''Return type''' : boolean
			; '''Default return value''' : false

	=== <tt>prevent_local_passwords()</tt>===		=== <tt>prevent_local_passwords()</tt>===

Nadavkav: /* user_update_password($user, $newpassword) */

2018-07-16T16:40:11Z

user_update_password($user, $newpassword)

← Older revision		Revision as of 16:40, 16 July 2018
Line 100:		Line 100:
	=== <tt>user_update_password($user, $newpassword)</tt>===		=== <tt>user_update_password($user, $newpassword)</tt>===
	Update the user's password.		Update the user's password.

			How passwords are stored in the DB (mdl_user.password): [https://moodle.org/mod/forum/discuss.php?d=235504#p1023177 forum discussion]

	=== <tt>user_update($olduser, $newuser)</tt>===		=== <tt>user_update($olduser, $newuser)</tt>===

Mudrd8mz: Simplify the strings related info, remove the link to the obsolete page Places_to_search_for_lang_strings

2017-09-06T11:24:17Z

Simplify the strings related info, remove the link to the obsolete page Places_to_search_for_lang_strings

← Older revision		Revision as of 11:24, 6 September 2017
Line 40:		Line 40:
	# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.		# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.
	# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''		# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''
	# If you don't like seeing <nowiki>[[auth_sentrytitle]]</nowiki> as the name of your plugin in the Moodle UI, you'll need to create language files for your plugin. Do this by creating the directory <tt>/auth/sentry/lang</tt>, and under it, a directory for each language that your installation needs to support. (Example: <tt>/auth/sentry/lang/en</tt>.) Within each of these language directories, create a file called <tt>auth_sentry.php</tt>. That file should set the desired value for <code>$string[~~'auth_sentrytitle'] for that language (use $string~~[~~'pluginname'~~] ~~for Moodle2)</code>. You can also set the plugin description by setting <code>$string['auth_sentrydescription'~~]~~</code>, and you can also assign other translatable strings that your plugin uses, in these files. '''Note:''' A folder named like '''en''' may not work~~ for everyone. Please refer to the lang folder under your moodle installation directory to get an idea about the language/locale codes used in your moodle installation. For example, the lang folder in own users system contained folders named '''en''' and '''zh-cn'''. He emulated the same in the lang folder of the auth plugin and the plugin picked up the title and description strings immediately. ([[Places_to_search_for_lang_strings\|More info on how Moodle handles language]]).		# If you don't like seeing <nowiki>[[auth_sentrytitle]]</nowiki> as the name of your plugin in the Moodle UI, you'll need to create language files for your plugin. See [[String API]] for details.
	# If you want to configure your plugin through the Moodle UI, implement <tt>config_form()</tt> and <tt>process_config()</tt> in the plugin class. You might find it convenient to use the 'db' plugin as a model for this. The plugin's config settings can then be managed through the Manage authentication page by clicking on the Settings link for that plugin, and the values will be stored in the <tt>mdl_config_plugins</tt> table in the database.		# If you want to configure your plugin through the Moodle UI, implement <tt>config_form()</tt> and <tt>process_config()</tt> in the plugin class. You might find it convenient to use the 'db' plugin as a model for this. The plugin's config settings can then be managed through the Manage authentication page by clicking on the Settings link for that plugin, and the values will be stored in the <tt>mdl_config_plugins</tt> table in the database.

Maherne at 10:34, 21 June 2017

2017-06-21T10:34:22Z

← Older revision		Revision as of 10:34, 21 June 2017
Line 183:		Line 183:
	=== <tt>pre_user_login_hook(&$user)</tt>===		=== <tt>pre_user_login_hook(&$user)</tt>===
	This method is called from authenticate_user_login() right after the user object is generated. This gives the auth plugin an option to make modification to the user object before the verification process starts.		This method is called from authenticate_user_login() right after the user object is generated. This gives the auth plugin an option to make modification to the user object before the verification process starts.

			=== <tt>test_settings()</tt>===
			(From 3.3 onwards) If this method exists, the "manage authentication plugins" page will show a "test settings" link. The method should output notifications to let the user know whether the settings are correct, and what to do to rectify them if not.

	==See also==		==See also==

Sbourget at 18:08, 9 May 2017

2017-05-09T18:08:45Z

← Older revision		Revision as of 18:08, 9 May 2017
Line 145:		Line 145:

	=== <tt>config_form($config, $err, $user_fields)</tt>===		=== <tt>config_form($config, $err, $user_fields)</tt>===
	Prints a form for configuring this authentication plugin. It's called from admin/auth.php, and outputs a full page with a form for configuring this plugin.		Prints a form for configuring this authentication plugin. It's called from admin/auth.php, and outputs a full page with a form for configuring this plugin.
			This function has been deprecated in Moodle 3.3. You should use the [[Admin_settings]] API instead. For more information see [https://tracker.moodle.org/browse/MDL-12689]

	=== <tt>validate_form($form, $err)</tt>===		=== <tt>validate_form($form, $err)</tt>===
	Validate form data.		Validate form data.
			This function has been deprecated in Moodle 3.3. You should use the [[Admin_settings]] API instead. For more information see [https://tracker.moodle.org/browse/MDL-12689]

	=== <tt>process_config($config)</tt>===		=== <tt>process_config($config)</tt>===
	Processes and stores configuration data for this authentication plugin.		Processes and stores configuration data for this authentication plugin.
			This function has been deprecated in Moodle 3.3. You should use the [[Admin_settings]] API instead. For more information see [https://tracker.moodle.org/browse/MDL-12689]

	=== <tt>loginpage_hook()</tt>===		=== <tt>loginpage_hook()</tt>===

Jackermann: /* Interfacing to API's */

2017-01-04T17:18:04Z

Interfacing to API's

← Older revision		Revision as of 17:18, 4 January 2017
Line 177:		Line 177:
	=== <tt> loginpage_idp_list() </tt> ===		=== <tt> loginpage_idp_list() </tt> ===
	Override this method and return a list of Identification Providers (IDPs) that your authentication plugin supports. An array of associative arrays containing url, icon and name for the IDP. These will be displayed on the login page and in the login block.		Override this method and return a list of Identification Providers (IDPs) that your authentication plugin supports. An array of associative arrays containing url, icon and name for the IDP. These will be displayed on the login page and in the login block.

			=== <tt>pre_user_login_hook(&$user)</tt>===
			This method is called from authenticate_user_login() right after the user object is generated. This gives the auth plugin an option to make modification to the user object before the verification process starts.

	==See also==		==See also==

Johnok: Document loginpage_idp_list

2016-11-14T06:39:37Z

Document loginpage_idp_list

← Older revision		Revision as of 06:39, 14 November 2016
Line 174:		Line 174:
	=== <tt>can_be_manually_set()</tt> ===		=== <tt>can_be_manually_set()</tt> ===
	This function was introduced in the base class and returns false by default. If overriden by an authentication plugin to return true, the authentication plugin will be able to be manually set for users. For example, when bulk uploading users you will be able to select it as the authentication method they use.		This function was introduced in the base class and returns false by default. If overriden by an authentication plugin to return true, the authentication plugin will be able to be manually set for users. For example, when bulk uploading users you will be able to select it as the authentication method they use.

			=== <tt> loginpage_idp_list() </tt> ===
			Override this method and return a list of Identification Providers (IDPs) that your authentication plugin supports. An array of associative arrays containing url, icon and name for the IDP. These will be displayed on the login page and in the login block.

	==See also==		==See also==

Lameze: /* postlogout_hook() */

2015-10-06T07:35:30Z

postlogout_hook()

← Older revision		Revision as of 07:35, 6 October 2015
Line 166:		Line 166:

	=== <tt>postlogout_hook()</tt>===		=== <tt>postlogout_hook()</tt>===
	This replace the prelogout_hook method to avoid authentication plugins redirects before the event ~~userlogout~~ being triggered.		This method replace the prelogout_hook method to avoid authentication plugins redirects before the user logout event being triggered.
	At the moment the only authentication plugin using this method is CAS (SSO).		At the moment the only authentication plugin using this method is CAS (SSO).

← Older revision		Revision as of 13:09, 14 July 2021
Line 13:		Line 13:
	## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request.		## Runs <tt>loginpage_hook()</tt> for each plugin, in case any of them needs to intercept the login request.
	## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).		## Checks to make sure that the username meets Moodle's criteria (alphanumeric, with periods and hyphens allowed).
	## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <~~code~~>$user</syntaxhighlight> object. (Details of this code follow this main outline.)		## Calls <tt>authenticate_user_login()</tt> in <tt>/lib/moodlelib.php</tt>, which returns a <syntaxhighlight lang="php">$user</syntaxhighlight> object. (Details of this code follow this main outline.)
	## Determines whether authentication was successful (by checking whether <~~code~~>$user</syntaxhighlight> is a valid object) and, if not, sends them back to the login page with an error message. 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.		## Determines whether authentication was successful (by checking whether <syntaxhighlight lang="php">$user</syntaxhighlight> is a valid object) and, if not, sends them back to the login page with an error message. 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.

	For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):		For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):
Line 37:		Line 37:
	# Choose a name for your plugin. We'll use 'sentry' as an example below; change it to whatever name you have chosen.		# Choose a name for your plugin. We'll use 'sentry' as an example below; change it to whatever name you have chosen.
	# Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>. It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.		# Under your Moodle installation root, create the directory <tt>/auth/sentry</tt>. It should be sibling to existing auth plugin directories: 'db', 'nologin', 'none', etc.
	# Create the file <tt>/auth/sentry/auth.php</tt>. Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>. (You will need to <~~code~~>require_once</syntaxhighlight> the authlib file.)		# Create the file <tt>/auth/sentry/auth.php</tt>. Within the file, create a class <tt>auth_plugin_sentry</tt> that extends <tt>auth_plugin_base</tt> from <tt>/lib/authlib.php</tt>. (You will need to <syntaxhighlight lang="php">require_once</syntaxhighlight> the authlib file.)
	# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.		# Implement the <tt>user_login()</tt> function in your <tt>auth.php</tt> file, and create or override additional functions based on your plugin's requirements.
	# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''		# Log in to your Moodle installation as a site administrator and find, in the site administrator block, the page "Users -> Authentication -> Manage authentication". You will see your plugin in the list, appearing as <nowiki>[[auth_sentrytitle]]</nowiki>. You can enable it and move it up and down in the order. '''At this point, with the plugin enabled, your plugin is registered and will be used by Moodle in its authentication process.'''