Testing Security Best Practices – Learnosity Product & Developer Help

Learnosity customers commonly deliver a range of assessment scenarios from practice homework problems all the way to supervised testing in a lab with secure browsers. Using simple configuration options, our APIs are flexible enough to handle multiple degrees of security, and this article discusses some of our recommended best practices.

By default, a Learnosity assessment aligns with what you might call a medium level of security. That is, there’s no way for the student to get immediate feedback on a response (as one might with a practice question), but neither are any measures in effect to prevent validation information from reaching the client. This information is not particularly easy for the average student to find or understand, but it’s provided by default to support the use of public methods in the client for programmatic validation and decision making. When deciding to deviate from this default--to provide more or fewer validation options to the student--you can do so by editing questions and/or editing assessments.

Question- and Assessment-level Security Decisions

Much of how a question looks and behaves in an assessment is determined by the question's source data. Let’s start with a simple example, such as changing a multiple choice question's Font size setting (More options > Layout > Font Size in the authoring UI). Selecting large during authoring will increase the font size of that question only. As another example, enabling the same question's Shuffle options setting to true will shuffle the order of its distractors upon each new assessment attempt.

In some cases, you can override these settings at the assessment level with a property in the Items API initialization request object. Using the assess rendering type as an example, you can set the font size of all questions throughout the assessment to small. The following snippet shows where this appears in the Items API init JSON, and here’s an overview of the process.

{
  "config": {
    "configuration": {
      "fontsize": "small"
    }
  }
}

Ignoring Question Attributes

Not all question attributes are surfaced at the assessment level, however, and you may still want to apply such changes to every question in an assessment without editing them in your item bank. While it’s not possible to edit question data on the fly, it is possible to disable many question features at the assessment level. This is possible using the ignore_question_attributes property, found in the config section of the Items API request object.

For example, let’s say you wanted to disable the aforementioned question-level Shuffle options feature throughout an entire assessment. Doing so would mean that multiple choice options for all questions will appear in the same order in which they were authored. To achieve this, you need only add the property, in the same hierarchical position found in the question data, to the ignore_question_attributes array. Because shuffle_options appears at the top level of the question data, the relevant part of your Items API request object would look like this:

{
  "config": {
    "configuration": {
      "fontsize": "small",
    },
    "ignore_question_attributes": [
      "shuffle_options"
    ]
  }
}

That’s all there is to it. You can disable many question attributes this way, including properties found in all question types or just specific question types (as when shuffle options was disabled only affecting multiple choice questions.)

Strip validation data

As previously mentioned, the validation object is sent to the client by default as part of question data so developers can use public methods to score and validate question locally. The average student can’t always make sense of this information, but adept users may be able to parse some data so you may want to prevent it from reaching the client in high-security scenarios. To do so, just ignore the validation object to exclude it from the question data delivered to the student. :

"ignore_question_attributes": [
    "validation"
]

The question will still display correctly, and will score the same way on the server, but the validation data will not be part of the client-side assessment eliminating any possibility of a student reverse engineering correct answers.

Note that this also means you won’t be able to use validation-related public method at the client and, as such, won’t see correct/incorrect styles applied. This step must also be taken when delivering the assessment for the first time. It’s not possible to capture responses with validation intact, and then suppress validation at a later time.

Hide the Check Answer button

For practice and lower security testing, you may want to enable the Check Answer button when authoring specific questions. This button allows a student to validate a response instantly, without having to submit the assessment. Because this feature is enabled at the question level, this presents problems when using a question in both low and high security scenarios. You can satisfy both needs by adding the button during authoring, and suppressing the corresponding instant_feedback property when delivering an assessment.

"ignore_question_attributes": [
    "instant_feedback"
]

Suppress metadata

If you want to hide nested data, say a property in the metadata section, you can do that with the appropriate object syntax. For example, let’s say you were storing sample answers for essay questions that could be used by graders as a reference during manual scoring. Because manually scored questions have no validation object, you might use the Sample Answer metadata field to store these examples. This property is not found at the top level of the question data, but you can figure out the correct syntax by looking at a question’s source JSON and observing the nested levels of objects and properties. The correct form, in this case, is:

"ignore_question_attributes": [
    "metadata.sample_answer"
]

Additional Assessment Settings

Learnosity assessment APIs offer additional features that may be used in a variety of security settings. For example, you may want to control the time a student has to complete an assessment, or even allow a proctor to force-submit an assessment manually.

Forcing hard time limits

A few timing options allow a developer to control how a session is limited by time. For example, you can set a time limit for completing the assessment, and then determine if the API will automatically submit when time runs out. Here are some examples of time options.

{
    "config": {
        "time": [
            "max_time": 600,
            "limit_type": "hard",
            "warning_time": 60
        ]
    }
}

If you set the limit_type property to “hard”, the assessment will auto-submit, regardless of progress. If you choose “soft” as the value of this property, it will provide visual feedback to the student, then start counting overtime, and record that information with the session. This allows teachers to determine how to respond after submission.

Secure browsers

In high-security settings, you might choose to deliver assessments in a third-party secure browser. Learnosity APIs are compatible with secure browsers and, by default, offer no way to exit an assessment before it’s conclusion. In this scenario, no further action is required.

Save and Resume

For low-security environments, you may want to offer the student a chance to save and resume an assessment at a later time. To do so, you can add a save and quit button to an Items API region, such as the one seen in this demo (look for the disk icon in the right button region). The following excerpt shows its syntax within the right region:

{
    "config": {
        "regions": {
            "right": [
                {
                    "type": "save_button"
                }
            ]
        } 
    }
}

Admin Panel

It’s even possible for teacher, proctor, or administrator to override these settings, if the administration panel is enabled. The following snippet shows the admin panel enabled, with default options, and a SHA256-encrypted password. Changing any of these default values to false will disable that option in the panel.

{
    "config": {
        "administration": {
            "options": {
                {
                    "show_exit": true,
                    "show_extend": true,
                    "show_save": true,
                    "show_submit": true
                }
            },
            "pwd": "4ab6cffac3b7924dc52286b3bcf04c87f033f9cdac66fb97832ecfd86bb1f93d"
        }
    }
}

Consider your options and test your efforts

Because it’s possible to hide entire objects you may benefit from hiding multiple properties at once. For instance, a previous example prevented the entire validation object from reaching the client, and you could suppress the entire metadata object, if preferred. Just be aware that your apps may have need for other properties and you may need to be selective. Confirm your syntax, test to be sure that only the desired properties have been removed, and test your app to be sure it functions as desired.