Turn on the forceclean config setting when a user is logged in as a
different user. This is a precautionary measure, which forces all
user submitted content to be cleaned of JavaScript before rendering
it to the logged in as user.
This commit is part of work on Custom fields API,
to minimize commit history in moodle core the work of a team of developers was split
into several commits with different authors but the authorship of individual
lines of code may be different from the commit author.
We were already caching these preferences when a user object is provided
to get_user_preferences, or when $USER is provided.
This changee swaps get_user_preferences to use the global USER object
when the USER->id matches the userid supplied to the function.
We should only call this function when a user actually views a course. It is not called
automatically when a course context is validated from a webservice. It is called directly
from the core_course_view_course webservice.
CSRF protection for the login form. The authenticate_user_login function was
extended to validate the token (in \core\session\manager) but by default it
does not perform the extra validation. Existing uses of this function from
auth plugins and features like "change password" will continue to work without
changes. New config value $CFG->disablelogintoken can bypass this check.
Improve the format of the HTML representing a forum post.
1. Use <article> tag to mark it correctly.
2. Use <time> tag to include the real datetime information.
3. Use <address> tag to specify who and when the post came from.
4. Use heading level tags to mark the subject of each post.
5. Properly nest reply posts within their parent <article>
6. Use a header tab for each article to split the metadata from the content.
7. Use CSS to separate links, not text content.
Because posts are now nested properly, the heading for each one refers to it's own article
and we don't need to generate arbitrary heading level tags depending on how deep the post
is nested.
Whenever the role_capabilities table is changed, we need to remember
to clear the cache for the role(s) being modified. This is far simpler
when all of those changes happen in a single file, i.e. accesslib.php,
allowing other parts of the application to use the public functions
without requiring knowledge of the cache internals.
Thanks to MDL-49398, we can separate the combined user session and role
definition cache clearing function into two separate functions. At the
same time, we want to identify and remove mark_dirty() calls that were
added for role definition changes but were incorrectly left behind.
Change highlights:
- Remove unnecessary mark_dirty() calls performed after
assign_capability(), unassign_capability(), delete_role(),
deleted contexts, brand new contexts
- Move role definition cache clear from the user-centric
accesslib_clear_all_caches() to the newly created,
role-dedicated accesslib_reset_role_cache()
Places that display list of users (such as course participants page)
with additional identifier fields now respect the user's permission to
view other users' hidden profile fields.
This adds the ability to to add comments to ip lists in moodle.
Currently, the configiplist textentry box does not allow the user to annotate
the IP addresses defined. For example, I'd like to be able to define:
192.168.1.1 # London office
10.1.1.1 # New york office
118.209.246.240 # My home IP
This would allow me to revisit this list after a few months, and remove
IP addresses that are no longer required - without having to manually confirm
each IP address
The standard password validation does some basic strength checks, but
there are a number of other ways to validate a password, such as
checking that it doesn't contain common words. Adding a plugin hook
here allows us to keep up with changes in best practice in this area
as it evolves over time.
Brendan Heywood