As open as Moodle is, it is tight with its security. It goes to great efforts to make sure that anyone accessing the system is supposed to be accessing the system, and they are supposed to be accessing it the way they are trying to.
Moodle has a powerful access control and permission system. At the core of the access system is the user account. Although it is possible to grant access to any visitor to your site without authenticating them, it doesn't allow them to do many interesting things. We will assume that you want to know who your users are, and that you will want them to have their own accounts.
A user account provides individual access via a username and password combination. These accounts are created by using authentication plugins. The bare minimum authentication is manual, where a user is created using the administration interface. The next, most common authentication is the e-mail-based system that allows users to create their own accounts using e-mail verification. In either case, a unique username and e-mail address are required as well as a password. Passwords in Moodle are encoded with an MD5 hash function to make them unreadable and difficult to guess.
To get into the system, a user enters their username and password, and if correctly entered, they are granted access to the site. Logging in uses PHP's 'cookie' functions to set cookies into the current session and help identify the user throughout the site visit.
Permissions can be assigned within six contexts: site/global, course category, course, blocks and activities, user, and front page. There are seven built-in roles: administrator, teacher, non-editing teacher, student, course creator, authenticated user, and guest, all of which can be assigned in any one or more of the above contexts. Any number of customized roles can be created through the list of over 200 system capabilities. Each capability can be assigned one of four access levels: Not Set, Allow, Prohibit, and Prevent. Each user can have multiple roles that inherit permissions from all of the context levels applicable to a given access request from the user. The combination of these provides a powerful and flexible solution for administrators.
The standard system roles are:
An infinite number of custom roles can be generated by using the Moodle GUI and role definition screens.
To check and force a login from inside your code, a call to require_login is used. This function allows you to check if the user is logged in, and forces them to log in if this is required by the element that they are trying to access. For example, you can create a specific activity in a course that requires the user to be logged in. If the user is not logged in, then they will be redirected to the correct login function. This function also remembers what the user was accessing, so they can be returned there once they have successfully logged in.
Contexts are elements in the system associated with the defined context levels. On the code-side, contexts are defined in /lib/accesslib.php as follows:
define('CONTEXT_SYSTEM', 10);
define('CONTEXT_USER', 30);
define('CONTEXT_COURSECAT', 40);
define('CONTEXT_COURSE', 50);
define('CONTEXT_GROUP', 60);
define('CONTEXT_MODULE', 70);
define('CONTEXT_BLOCK', 80);
This means every instance of any of these levels is a context. There is only one 'SYSTEM', but there are many of the others, such as users, courses, and modules.
Capabilities are associated with context levels, and are specific access rules that can be granted to roles. Examples of capabilities are:
As developers, we can create capabilities to control access to our new functionality. Careful consideration should be given as to which context is the best location for a new capability. Capabilities should generally be placed at the lowest context level at which they can function. We will cover these topics in more detail as we work, in the chapters ahead.
Roles are specific identifiers that are associated with all contexts. Roles are primarily used to group capabilities for a context, so that these capabilities can be given to users. Capabilities are assigned to roles in specific contexts, either by default or by specific assignment (overriding).
Lastly, users can be assigned to roles in specific contexts. This assignment gives them the accesses defined by the capabilities in that role for that context.
So, to summarize:
Contexts are specific elements in Moodle
Roles are associated with all contexts
Capabilities are assigned to roles in a given context
Users are assigned roles in a given context
It is the role assignment at the context level being checked, and the capability that role has at that context, which determines whether a user can perform the requested action.
As you develop code for Moodle, you will need to keep this functionality in mind, so that you can design and build the access control that you want for your functions.