MDL-50925 auth_imap: Remove from core and into plugins DB
[moodle.git] / auth / README.txt
CommitLineData
faebaf0f 1This directory contains authentication modules.
2
139ebfdb 3Each of these modules describes a different way to
4check that a user has provided a correct
faebaf0f 5
139ebfdb 6 - username, and
faebaf0f 7 - password.
8
b9ddb2d5 9Even when external forms of authentication are being used, Moodle still
10maintains the internal "user" table with all the associated information about
11that user such as name, email address and so on.
faebaf0f 12
109e9581 13
b9ddb2d5 14Multiauthentication in Moodle 1.8
15-------------------------------------
16
17The active methods are set by the admin on the Configuration page. Multiple
18authentication plugins can now be used and ordered in a fail-through sequence.
19One plugin can be selected for interactive login as well (which will need to be
20part of the enabled plugin sequence).
faebaf0f 21
22
23email - authentication by email (DEFAULT METHOD)
24
25 - user fills out form with email address
139ebfdb 26 - email sent to user with link
faebaf0f 27 - user clicks on link in email to confirm
28 - user account is created
29 - user can log in
30
31
32none - no authentication at all .. very insecure!!
139ebfdb 33
faebaf0f 34 - user logs in using ANY username and password
35 - if the username doesn't already exist then
36 a new account is created
139ebfdb 37 - when user tries to access a course they
faebaf0f 38 are forced to set up their account details
39
109e9581 40
41nologin - user can not log in, login as is possible
42
43 - this plugin can be used to prevent normal user login
44
45
88478a66 46manual - internal authentication only
47
48 - user logs in using username and password
49 - no way for user to make their own account
50
faebaf0f 51
52ldap - Uses an external LDAP server
2ee53d15 53
54 - user logs in using username and password
55 - these are checked against an LDAP server
56 - if correct, user is logged in
57 - optionally, info is copied from the LDAP
58 database to the Moodle user database
d1b4e172 59
2ee53d15 60 (see the ldap/README for more details on config etc...)
d1b4e172 61
62
d1b4e172 63db - Uses an external database to check username/password
139ebfdb 64
d1b4e172 65 - user logs in using username and password
66 - these are checked against an external database
67 - if correct, user is logged in
68 - if the username doesn't already exist then
69 a new Moodle account is created
5b06bef1 70
71
b9ddb2d5 72--------------------------------------------------------------------------------
5b06bef1 73
74Authentication API
b9ddb2d5 75------------------
76
109e9581 77
78AUTHENTICATION PLUGINS
79----------------------
b9ddb2d5 80Each authentication plugin is now contained in a subfolder as a class definition
81in the auth.php file. For instance, the LDAP authentication plugin is the class
82called auth_plugin_ldap defined in:
83
84 /auth/ldap/auth.php
85
86To instantiate the class, there is a function in lib/moodlelib called
87get_auth_plugin() that does the work for you:
88
89 $ldapauth = get_auth_plugin('ldap');
90
109e9581 91Auth plugin classes are pretty basic and should be extending auth_plugin_base class.
92They contain the same functions that were previously in each plugin's lib.php file,
93but refactored to become class methods, and tweaked to reference the plugin's instantiated
94config to get at the settings, rather than the global $CFG variable.
95
5117d598 96When creating new plugins you can either extend the abstract auth_plugin_base class
109e9581 97(defined in lib/authlib.php) or create a new one and implement all methods from
98auth_plugin_base.
b9ddb2d5 99
109e9581 100The new plugin architecture allows creating of more advanced types such as custom SSO
f5fd4347 101without the need to patch login and logout pages (see *_hook() methods in existing plugins).
b9ddb2d5 102
103Configuration
104-----------------
105
106All auth plugins must have a config property that contains the name value pairs
107from the config_plugins table. This is populated using the get_config() function
108in the constructor. The settings keys have also had the "auth_" prefix, as well
109as the auth plugin name, trimmed. For instance, what used to be
110
111 echo $CFG->auth_ldapversion;
112
113is now accessed as
114
115 echo $ldapauth->config->version;
116
117Authentication settings have been moved to the config_plugins database table,
118with the plugin field set to "auth/foo" (for instance, "auth/ldap").
119
b9ddb2d5 120
121Method Names
122-----------------
123
124When the functions from lib.php were ported to methods in auth.php, the "auth_"
125prefix was dropped. For instance, calls to
126
127 auth_user_login($user, $pass);
128
129now become
130
131 $ldapauth->user_login($user, $pass);
132
133this also avoids having to worry about which auth/lib file to include since
134Moodle takes care of it for you when you create an instance with
135get_auth_plugin().
136
109e9581 137The basic class defines all applicable methods that moodle uses, you can find
138more information in lib/authlib.php file.
5b06bef1 139
b9ddb2d5 140
109e9581 141Upgrading from Moodle 1.7
142-----------------------------
b9ddb2d5 143
109e9581 144Moodle will upgrade the old auth settings (in $CFG->auth_foobar where foo is the
145auth plugin and bar is the setting) to the new style in the config_plugin
146database table.
4db13f94 147
148
149
150Upgrading from Moodle 1.8
151------------------------------
152
153user_activate() method was removed from public API because it was used only from user_confirm() in LDAP