MoodleDocs - User contributions [en]

File:passwordresetpresent.png

2013-07-18T22:06:25Z

Peterbulmer: Peterbulmer uploaded a new version of "File:passwordresetpresent.png"

File:passwordresetpresent.png

2013-07-18T22:00:59Z

Peterbulmer: Peterbulmer uploaded a new version of "File:passwordresetpresent.png"

File:passwordresetpresent.png

2013-07-18T21:57:57Z

Peterbulmer: Peterbulmer uploaded a new version of "File:passwordresetpresent.png"

File:passwordresetnew.png

2013-07-18T21:57:25Z

Peterbulmer: Peterbulmer uploaded a new version of "File:passwordresetnew.png"

Password Reset Proposal

2013-07-18T09:26:33Z

Peterbulmer:

The password reset process in Moodle is longer and more invloved than it needs to be.

Currently there are 14 steps in the standard password reset process. Step 1 is the user clicking the link on the login page, step 2 is the system displaying the password-reset-request form, step3 the user enters their identifier ..... right through to the user being logged in (14).

I think we can reduce this to 8 steps; improving usability without comprimising security.

In both the existing, and proposed solutions, the user starts with the above steps 1-3, but the processes diverge at step 4, before re-converging at the last step ("User Logged in").

Processes side-by-side, step 4 to completion:
{|
|-
! Current process
! Proposed process
|- valign="top"
| [[File:passwordresetpresent.png]]
| [[File:passwordresetnew.png]]
|}

As I see it the essential steps for password resetting are:
* Establish who the resetting user (resetter) claims to be (the target user account)
* Verify that the resetter has access to the target user account's email inbox
* Obtain acceptable new password from resetter

The proposed process ticks of all these items.

A few extra details:
In the proposed reset process, Moodle stores a record of the password resets requested, the one-time token that resulted. The email sent to the user will contain a link to the password setting page. When the user posts the form containing the two copies of the new password, along with the original token, the password is updated, the token deleted, and the user is logged in. There will need to be an admin setting to specify how long to allow for the email sending - (30 min default), and a job to delete tokens that are significantly out of date.

Advantages of the new process are:
* Only requires one email step
* Doesn't send the user any passwords which they don't end up keeping
* Doesn't require the user to copy and paste at any stage.
* Is fast
* Secure
* Aligns well with other site's password reset routines.

2008-12-23T02:37:04Z

Peterbulmer: New page: === Jargon === * IDP Identity Provider: An application (Moodle) fulfiling the functionality of tying a user to a profile. * IDPA IDP Administrator * CP Content provider: An application (Mo...

=== Jargon ===
* IDP Identity Provider: An application (Moodle) fulfiling the functionality of tying a user to a profile.
* IDPA IDP Administrator
* CP Content provider: An application (Moodle) fulfiling the functionality of course material host.
* CPA CP Administrator

== Role Assignments ==
In existing mnet (Moodle < v2.0) IDPA selected a course published by a CP, then they identified local users that they wanted to be enrolled in that course. The CP would then assign a role to the selected users in the context of the course specified. The role assigned was "default role for users in a course" (usually ''student'').

=== Problems ===
The current setup has a number of problems:
* No support for allocating more than one role
* No support for any form of automated enrolment/role assignment (all plugins must be extended to have any functionality wrt remote mnet courses.
* Dedicated tables for storing information about mnet courses, and enrolments
* No allowance made to align grades output by the CP with the enrolment of the student in the course.

=== Proposal ===
Proposal I'd like to put to a client addresses all these points in the following ways:

* '''Allow CPA to specify that they trust the IPA to allocate more than just the student role'''. This information would be set per mnet peer, and should probably default to allowing students, denying everything else (the setting which matches most pre-existing configurations). This information would be stored in a new table mdl_mnet_authorisied_roles, CPA would tick all roles they trust the IDPA to allocate.
* Allow IPA to map their system roles to permitted CP roles on a per-mnet-peer basis. Most commonly the IDPA would map 'teacher' to 'CP_teacher', 'student' to 'CP_student' and 'non-editing teacher' to 'CP_non-editing teacher' (the 'CP_' recognising that the roles are not necessarily exactly the same). This information would be stored in a new table mdl_mnet_role_mapping
* '''Allow all pre-existing enrolment mechanisms to enrol users in remote courses.''' - Remove the use of tables dedicated to tracking remote courses, and remote course enrollments, instead storing the same information with local course information, (mdl_course) with an additional field ('mnetlinkid' or similar) which identifies that users trying to view the course should be directed to jump to the address described in the mdl_mnet_link table. IPA would specify which remote course they want this local course to link to, in effect converting the local course to a shell for the remote course. All enrolment plugins would continue to manipulate the user assignment in the 'local' course, with the hook being that they would spawn a request to the remote moodle adding the user to the remote course. Finally, using mdl_course for remote and local courses alike would provide a good location for grades to be stored when/if they are shipped back from the CP as part of (other) future mnet functionality.
* An additional capability 'can see shell course' - allocated by default to at least the administrator role, allowing them to see the contents of the local course without being redirected to jump.php to see the real thing.