This document outlines the components involved in the edX proctoring system. It should serve as a guide to orient developers on what components exist, how they interact, and where to find the source code in our platform.
During a proctored exam, LMS renders different student views based on the status of that exam attempt. The LMS renders the views by calling into edx-proctoring and loading the relevent html templates.
The goal of these interstitials is to guide the learner through the many steps of attempting a proctored exam, where at many steps there are critical details about what the learner needs to do or understand. As such, some of the copy on these interstitials is very important.
Notable Code:
- LMS render student_view()
- edx-proctoring template logic
- edx-proctoring interstitial templates
- Learning MFE
- React lib for special exams
Python plugin that handles the bulk of edX's proctoring logic. It hosts the models for proctored exam configuration and learner attempts. It exposes a REST and Python interface to manage them. edx-proctoring is also responsible for calling out to the provider's backend (through a plugin) to keep exam configuration and learner attempts in-sync between the two systems.
Integration layer to handle making REST/http requests to the provider's backend. This can exist as a Python module or be committed directly into edx-proctoring as a backend.
More information on configuring backends
We have two real backends used in production:
- Proctortrack: https://github.com/joshivj/edx-proctoring-proctortrack
- RPNow: https://github.com/openedx/edx-proctoring/blob/447c0bf49f31fa4df2aa2b0339137ccfd173f237/edx_proctoring/backends/software_secure.py
For testing backends see mockprock
A set of functions called by edX courseware to emit browser messages. Certain providers may choose to handle these events to facilitate direct communication between the browser and a desktop application. Messages are emitted when the exam content is started and ended. Additionally a ping message will poll at a configurable interval. Successful callback responses are required for each of these messages to keep the exam from entering an error state.
Message Interface: exam_action_handler.js
This is an optional component currently used by Proctortrack and our Mockprock provider.
A JavaScript worker included as part of the the provider's python plugin. This will handle any messages emitted by the edX web application and interface directly with the proctoring software running on the learner's machine.
Example worker: proctortrack_custom.js
See Example Action Sequence for how this interface fits into the exam process.
When a learner first enters a proctored exam subsection an exam attempt is created in the edX system. User actions and the proctoring provider will update the status of this attempt as the exam is completed and reviewed. The following diagram describes the flow through those status updates.
Detailed descriptions of each potential attempt state can be found below. It should be noted that there are minor differences in the review process between RPNow and Proctortrack exams.
This figure does not include error states or display of unmet prerequite requirements.
The diagrams below describes the happy-path of interactions between components to sucessfully begin a proctored exam. These examples matches Proctortrack's backend implementation and includes any JavaScript events handled by the proctoring app.
