MoodleDocs - User contributions [en]

Moodle 3.2 release notes

2017-01-04T18:54:09Z

Jackermann:

[[Releases]] > {{FULLPAGENAME}}

Release date: 5 December 2016

Here is [https://tracker.moodle.org/secure/IssueNavigator!executeAdvanced.jspa?jqlQuery=project+%3D+mdl+AND+resolution+%3D+fixed+AND+fixVersion+in+%28%223.2%22%29+ORDER+BY+priority+DESC&runQuery=true&clear=true the full list of fixed issues in 3.2].

See our [https://docs.moodle.org/32/en/New_features New Features page] for a more user-friendly introduction to Moodle 3.2 with screenshots.

If you are upgrading from previous version, make sure you read the [https://docs.moodle.org/32/en/Upgrading Upgrading] documentation.

==Server requirements==

These are just the minimum supported versions. We recommend keeping all of your software up-to-date.

* Moodle upgrade: Moodle 2.7 or later (if upgrading from earlier versions, you must upgrade to 2.7.14 as a first step)
* PHP version: minimum PHP 5.6.5 ('''important!''' minimum PHP version has changed since Moodle 3.1). PHP 7.0 is supported but has some [https://docs.moodle.org/dev/Moodle_and_PHP7#Can_I_use_PHP7_yet.3F engine limitations]. PHP 7.1 is supported (released 1.12.2016.

=== Database requirements ===

Moodle supports the following database servers. Again, version numbers are just the minimum supported version. We recommend running the latest stable version of any software.

{| class="nicetable"
|-
! Database
! Minimum version
! Recommended
|-
| [http://www.postgresql.org/ PostgreSQL]
| 9.1
| Latest
|-
| [http://www.mysql.com/ MySQL]
| 5.5.31
| Latest
|-
| [https://mariadb.org/ MariaDB]
| 5.5.31
| Latest
|-
| [http://www.microsoft.com/en-us/server-cloud/products/sql-server/ Microsoft SQL Server]
| 2008
| Latest
|-
| [http://www.oracle.com/us/products/database/overview/index.html Oracle Database]
| 10.2
| Latest
|}

==Client requirements==

=== Browser support ===
Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

Desktop:
* Chrome
* Firefox
* Safari
* Edge
* Internet Explorer

Mobile:
* MobileSafari
* Google Chrome

For the best experience and optimum security, we recommend that you keep your browser up to date. https://whatbrowser.org

Note: Legacy browsers with known compatibility issues with Moodle 3.2:
* Internet Explorer 10 and below
* Safari 7 and below

==Major features==

===Highlights===

* MDL-55071, MDL-55074 - New "Boost" Bootstrap 4 theme, usability improvements of the navigation
* MDL-54682 - [https://docs.moodle.org/32/en/Messaging Messaging] UI improvements
* MDL-52777 - [https://docs.moodle.org/32/en/User_tours User tours] - walkthoughs/instructional overlays for first time user on page
* MDL-38158 - Pluggable media players in Moodle; Video.JS player
* MDL-55324 - Easier embedding videos in audios in Atto editor with poster, subtitles and other attributes
* MDL-54987 - New chart API and library

===Mobile app===

* MDL-53870 - Support for offline quizzes in the Mobile app
* MDL-53777 - Include support for login via the browser in the new Moodle Mobile admin tool
* MDL-55059 - Support Smart App Banners for iOS
* MDL-56607 - Move mobile settings to top-level admin

===External tool (LTI)===

* MDL-49609 - Add LTI Content Item support
* MDL-47113 - Open LTI Tools in new Window, add link when popup is blocked
* MDL-53832 - LTI v2.0 support

===Assignment===

* MDL-38105 - Allow negative score for rubric and change default grade calculation method
* MDL-29795 - [https://docs.moodle.org/32/en/Using_Assignment#Overriding_assignment_deadlines Assignment deadline overrides] for an individual or group
* MDL-54872 - Sort blind marked assignment by blind ID instead of userid

===Quiz===

* MDL-48629 - Change the separator for matching correct answer feedback
* MDL-3782 - Allow multiple answers in cloze MULTICHOICE question type
* MDL-55200 - Show coordinates in ddmarker questions to simplify dropzone creation
* MDL-27072 - Quiz reports now work on very large courses, rather than running out of memory

===Choice===

* MDL-18592 - Allow teacher to make choices for students
* MDL-11369 - Show choice deadline in the course calendar
* MDL-55140 - Allow to specify open and close dates separately
* MDL-37946 - When choice display is set horizontal or vertical apply it to both options and results display

===Forum===

* MDL-18599 - Upon restore, association of "owner" of single simple discussion forum type defaults to user completing restore. Solution: hide author of the first post
* MDL-37669 - Forum: Make "Mark as read on notification" a user preference
* MDL-55982 - Add support for automatic locking of an individual forum discussion after a period of inactivity

===Other activity modules===

* MDL-55327 - Lesson: option to duplicate pages
* MDL-55868 - Book: various usability improvements
* MDL-56100 - Folder: Display in recent activity block
* MDL-54945 - Workshop: integrate with portfolio API
* MDL-48944 - Survey: activity completion condition on survey completion
* MDL-44712 - SCORM: improve Multi-SCO completion handing in activity completion
* MDL-55158 - Database activity: add start and end dates to the calendar
* MDL-14448, MDL-55464, MDL-55254, MDL-55251, MDL-49029 - Add standard capability "mod/xxxxx:view" to Lesson, Label, Database, Chat and Choice activities
* MDL-55866 - Remember editor disabled setting on a per-activity setting

===Global search===

* MDL-54794 - Add users to global search
* MDL-54973 - Add messages to global search
* MDL-55127 - Add database entries to global search
* MDL-53222 - Revise admin settings/report for global search for improved usability

===Other improvements===

* MDL-30179 - Allow teacher to toggle to/from "user view" in the User report in the gradebook (some items may be hidden for students but not teachers)
* MDL-53048 - New "password" fields that are not auto-filled by password managers
* MDL-55767 - [https://docs.moodle.org/32/en/Competency_frameworks Competency frameworks import]
* MDL-29110 - Specify welcome email sender in enrol_self, or send emails from system noreply address
* MDL-22078 - Store "End date" for each course to be used in reports and analytics
* MDL-53399 - 'Activity chooser off/on' option moved to user preferences
* MDL-54751 - Introduce asynchronous module deletion so that recycle bin backup does not slow down editing process for the teacher
* MDL-55981 - By default non-editing teacher should not be able to access all groups (roles in upgraded sites are not changed)
* MDL-31356 - IMS Enterprise enrol plugin added features
* MDL-43230 - Support revoking awarded badges
* MDL-50286 - Allow to filter report_log by origin : Logs clogged up with events listed as origin cli
* MDL-51749 - Add Ability to Export Calendar for user or group events
* MDL-50888 - Antivirus: Implement ClamAV virus scanning using unix sockets.
* MDL-54617 - Always show count of online users in the online users block
* MDL-54680 - Offer cartridges in LTI provider

=== For administrators ===

Please read carefully: [https://docs.moodle.org/32/en/Upgrading#Possible_issues_that_may_affect_you_in_Moodle_3.2 Possible issues that may affect you in Moodle 3.2]

* MDL-44467 - Return-Path should use no-reply address instead of support email; use only no-reply email or allowed domains in "From" header
* MDL-48468 - Add a Redis cache store to Moodle core
* MDL-39117 - Add a APCu cache store to Moodle core
* MDL-54947 - Update PostgreSQL binary (bytea) handling and improve connection performance
* MDL-48766 - Support IPv6 in IP lookup tool
* MDL-55124 - Support for connection pooler (pgbouncer) in PostgreSQL connection
* MDL-55916 - Maintenance mode should serve a http 503 instead of a 200
* MDL-54606 - Sessions: Add support for Redis as a session_class_handler
* MDL-53366 - Antivirus clamav: Remove "Quarantine directory" settings parameter.
* MDL-55791 - Add capability to allow certain users through Maintenance mode

==== Plugins removal ====

If you are using any of the following you need to download and install the plugins or otherwise they will be removed following 3.2 upgrade:

* MDL-55837 - Themes [https://moodle.org/plugins/theme_base Base] and [https://moodle.org/plugins/theme_canvas Canvas] - these themes can not be used by themselves but they may be used as parent themes
* MDL-49533 - Repository [https://github.com/moodlehq/moodle-repository_alfresco Alfresco] for Alfresco 4.2 and below, see [https://docs.moodle.org/32/en/Alfresco_repository Alfresco repository documentation]
* MDL-55927 - Authentication method [https://github.com/moodlehq/moodle-auth_radius Radius]. This plugin uses mcrypt library and is not compatible with PHP 7.1
* MDL-38158 - Media players [https://github.com/moodlehq/moodle-media_flowplayerflash Flowplayer], [https://github.com/moodlehq/moodle-media_wmp Windows media player], [https://github.com/moodlehq/moodle-media_realplayer RealPlayer], [https://github.com/moodlehq/moodle-media_quicktime Quicktime] - these media players were present in Moodle 3.1 but removed in 3.2. They need to be installed in media/player directory

=== Web services ===

* MDL-31465 - Incorporate user suspension into web services
* MDL-45639 - Web Service for SSO (auto-login from the app to the site)
* MDL-55923 - Improve the behavior of deleted tokens on password reset
* MDL-55928 - New Web Service gradereport_user_get_grade_items
* MDL-55100 - New Web Service core_course_get_courses_by_field

=== For developers ===

* MDL-55071, MDL-55074 - New "Boost" Bootstrap 4 theme, block and navigation changes (see [[Boost_Navigation]] and [[Themes|Themes]])
* MDL-38158 - Introduction of Media players plugin type (see [[Media_players|Media players]])
* MDL-50937 - JQuery updated to version 3.1 (see [[jQuery]])
* MDL-54987 - New chart API and library (see [[Charts_API]])
* MDL-55727 - AMD modal module introduced (see [[AMD_Modal|AMD Modal documentation]])
* MDL-52127 - Linting for Javascript with ESLint (see [[Linting#Javascript_.28ESLint.29|Linting Javascript]])
* MDL-55058 - Linting for CSS with stylelint (see [[Linting#CSS.2FSCSS.2FLESS_.28stylelint.29|Linting CSS]])
* MDL-48114 - Moodle can now be downloaded via composer (see [[Composer#Use_composer_to_download_moodle_code|Composer]])
* MDL-55091 - phpunit has been upgraded to 5.x
* MDL-55072 - Behat now supports different themes. (See [[Running_acceptance_test]])
* MDL-55048 - Grunt and npm build dependencies now require node version 4 or above
* MDL-31243 - New get_with_capability_sql function for retrieving SQL for finding users with capability in the given context
* MDL-49599 - Boxnet v1 API is now deprecated
* MDL-53306 - New authentication plugin method added which is called before user login (see [[Authentication_plugins#pre_user_login_hook.28.26.24user.29|Authentication plugins]])
* MDL-47162 - Course ID is now required in message events
* MDL-55141 - Debugging option added for scheduled tasks from CLI (see [https://docs.moodle.org/en/Administration_via_command_line#Scheduled_tasks Scheduled tasks documentation])
* MDL-54941 - Add filesize as a new field returned in all the Web Services returning file information
* MDL-56082 - Expose external authentication methods (loginpage_idp_list) in login block (see [[Authentication_plugins#loginpage_idp_list.28.29|Authentication plugins]])

==See also==
*[[Moodle 3.1 release notes]]

[[Category:Release notes]]
[[Category:Moodle 3.2]]

[[fr:Notes de mise à jour de Moodle 3.2]]
[[es:Notas de Moodle 3.2]]

Authentication plugins

2017-01-04T17:18:04Z

Jackermann: /* Interfacing to API's */

==Introduction==

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.
=== Overview of Moodle authentication process ===
[[File:1.9.11_login_element.png|203px||thumb|right|The login UI element in Moodle 1.9]]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. 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.

For the regular plugins the following happens (skipping some minor details and rarer scenarios):

# The default login page (<tt>/login/index.php</tt>) is displayed. OR, if a system administrator has set the Alternate Login URL on the "Manage authentication" page, that URL will be displayed.
# A user enters their credentials and submits the form.
# The handler code in <tt>/login/index.php</tt> runs:
## Gets a list of enabled authentication plugins.
## 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).
## 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.)
## 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.

For the 3rd party auth plugins the process could look like this (eg CAS, SAML, OpenID etc):
# Access a protected page but isn't logged in, so moodle calls <tt>pre_loginpage_hook()</tt> on each enabled plugin, which may redirect to the 3rd party login page
# Or if they go directly to the login page moodle calls <tt>loginpage_hook()</tt> on each enabled plugin, which may redirect to the 3rd party login page
# The user enters their credentials and authenticates on the 3rd party page
# 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 auth plugin now validates the token or decrypts the assertion, does any other checking as required and then logs the user in using <tt>complete_user_login($user)</tt>. If this happens inside <tt>pre_loginpage_hook()</tt> then the user continues on their way, or if inside <tt>loginpage_hook()</tt> or another custom page then the plugin should redirect to the wantsurl.

Note that in this scenario above <tt>user_login($username, $password)</tt> is never called and should probably return false.

==History==
Authentication plugins exist from 1.9
==Example==
[http://moodle.org/plugins/view.php?plugin=auth_googleoauth2 Google / Facebook / Messenger Oauth2 Authentication plugin]

==Template==
Please see Moodle '''none''' authentication plugin (auth/none), it's the perfect plugin template to start with.

==Naming convention==
==File structure==
# 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.
# 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.)
# 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.'''
# 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 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.

==Interfacing to API's==

=== <tt>authenticate_user_login()</tt>===
That's the main outline, but a lot of interesting stuff happens in <tt>authenticate_user_login()</tt>:

# It gets a list of enabled authentication plugins.
# It looks up the username in the mdl_user table to see if they are allowed to log in, and which authentication plugin handles their login requests. (This will be the plugin that handled their first-ever login request.)
# It creates a user object, which will contain the data from <tt>mdl_user</tt> if the username is known; if not, it will be an empty object.
# It does the following with the authentication plugin (note that for a username unknown to Moodle, it will do these steps for each authenticated plugin until one succeeds or it has tried them all):
## Calls the <tt>user_login()</tt> function provided by that plugin, which returns a boolean value based on whether the credentials authenticate or not. If the result is false (not authenticated), skips the rest of the steps below and continues to the next plugin.
## If the plugin authenticates against an external system (not Moodle's user database), its <tt>update_user_record()</tt> function is called to get the user's name, contact info, etc.
## Creates the Moodle user record if it doesn't already exist.
## Calls the plugin's <tt>sync_roles()</tt> function.
## Notifies each enabled authentication plugin that the user successfully authenticated, by calling each one's <tt>user_authenticated_hook()</tt> function.
# It returns the user object if everything was successful, or false if no plugin was able to successfully authenticate the credentials.

=== <tt>user_login($username, $password)</tt>===
This must be rewritten by plugin to return boolean value, returns true if the username and password work and false if they are wrong or don't exist.

=== <tt>can_change_password()</tt>===
Returns true if this authentication plugin can change users' password.

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

=== <tt>change_password_url()</tt>===
Returns the URL for changing the users' passwords, or empty if the default URL can be used.

=== <tt>can_edit_profile()</tt>===
Returns true if this authentication plugin can edit the users' profile.

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

=== <tt>edit_profile_url()</tt>===
Returns the URL for editing users' profile, or empty if the defaults URL can be used.

=== <tt>is_internal()</tt>===
Returns true if this authentication plugin is "internal". Internal plugins use password hashes from Moodle user table for authentication.

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

=== <tt>prevent_local_passwords()</tt>===
Indicates if password hashes should be stored in local moodle database. This function automatically returns the opposite boolean of what is_internal() returns. Returning true means MD5 password hashes will be stored in the user table. Returning false means flag 'not_cached' will be stored there instead.

; '''Return type''' : boolean
; '''Default return value''' : !$this->is_internal()

=== <tt>is_synchronised_with_external()</tt>===
Indicates if moodle should automatically update internal user records with data from external sources using the information from get_userinfo() method. This function automatically returns the opposite boolean of what is_internal() returns.

; '''Return type''' : boolean
; '''Default return value''' : !$this->is_internal()

=== <tt>user_update_password($user, $newpassword)</tt>===
Update the user's password.

=== <tt>user_update($olduser, $newuser)</tt>===
Called when the user record is updated. It will modify the user information in external database.

=== <tt>user_delete($olduser)</tt>===
User delete requested. Internal user record had been deleted.

=== <tt>can_reset_password()</tt>===
Returns true if plugin allows resetting of internal password.

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

=== <tt>can_signup()</tt>===
Returns true if plugin allows resetting of internal password.

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

=== <tt>user_signup($user, $notify=true)</tt>===
Sign up a new user ready for confirmation, password is passed in plaintext.

=== <tt>can_confirm()</tt>===
Returns true if plugin allows confirming of new users.

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

=== <tt>user_confirm($username, $confirmsecret)</tt>===
Confirm the new user as registered.

=== <tt>user_exists($username)</tt>===
Checks if user exists in external db.

=== <tt>password_expire($username)</tt>===
Returns number of days to user password expires.

=== <tt>sync_roles()</tt>===
Sync roles for this user - usually creator

=== <tt>get_userinfo($username)</tt>===
Read user information from external database and returns it as array.

=== <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.

=== <tt>validate_form($form, $err)</tt>===
Validate form data.

=== <tt>process_config($config)</tt>===
Processes and stores configuration data for this authentication plugin.

=== <tt>loginpage_hook()</tt>===
Hook for overriding behaviour of login page.

=== <tt>pre_loginpage_hook()</tt>===
Hook for overriding behaviour of prior to redirecting to the login page, eg redirecting to an external login url for SAML or OpenID authentication. If you implement this you should also implement loginpage_hook as the user may go directly to the login page.

=== <tt>user_authenticated_hook($user, $username, $password)</tt>===
Post authentication hook. This method is called from authenticate_user_login() for all enabled auth plugins.

=== <tt>prelogout_hook()</tt>===
Pre logout hook.

=== <tt>postlogout_hook()</tt>===
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).

=== <tt>logoutpage_hook()</tt>===
Hook for overriding behaviour of logout page.

=== <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.

=== <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.

=== <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==

* [[Authentication API]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=102070 Overview of entire authentication code flow] forum discussion
* Using Moodle [http://moodle.org/mod/forum/view.php?id=42 User authentication forum]
* Moodle Docs [[:en:Manage authentication|Manage authentication]]
* [[:en:Authentication FAQ|Authentication FAQ]]

[[Category:Authentication]]
[[Category:Plugins]]

[[fr:Méthodes_d'authentification]]