Background

Currently, SCORM Cloud uses cookies to determine if a learner is authorized to view course content. The way this works is that when a learner launches a course, SCORM Cloud sets the authorization cookies in the browser. Cloudfront then uses these cookies any time the browser requests a piece of content to verify that the browser is allowed to see it.

If there are any issues during the authentication process, the learner will receive an error message like the one above. From here, the best way to troubleshoot the issue using this guide. Those steps should solve most of the cases where this error is seen.

Who should use Content Vault?

There are certain situations where the above guide won't work, or isn't the most viable solution to ensure you can deliver your content seamlessly and error-free. Here are just a couple of situations where SCORM Cloud's new Content Vault feature (cookieless content authorization) is a good solution.

iOS users

With recent updates to iOS, the use of third-party cookies has become more and more difficult. Therefore, delivering your content via an app or browser on a mobile device is tricky since you would have to tell each user to enable the use of third-party cookies on their device. Using cookieless content auth allows your users to launch your content without having to change any of the default settings.

Dispatched courses launched in an iframe

If you use SCORM Cloud to dispatch courses and then launch those dispatches in an iframe, you may run into issues with using third-party cookies. Most modern browsers have a feature that keeps frames in one domain from setting cookies on a frame with a different domain. This is problematic when using SCORM Cloud's Dispatch since the frame with source "cloud.scorm.com" is trying to set a cookie on a frame with another domain. When using cookieless content auth, there are no cookies to set so your users won't run into this issue.

Chrome 80

You may have heard about Google's changes in Chrome 80. Chrome released version 80 on February 4th, 2020 which changes the way the browser handles third-party cookies. While we've done as much on the internals of SCORM Cloud to mitigate this issue, there may be times when the changes in Chrome 80 will cause issues—namely with embedded (i.e. launched in an iframe) content NOT using HTTPS. The best solution is to change all of your communications with SCORM Cloud into using HTTPS. If that isn't an option, cookieless content auth might be a solution.

How do you use cookieless content auth?

Right now, there are two ways to use cookieless content auth: at the destination level and when building a registration launch link.

First, let's look at some of the options you can specify when using cookieless content auth. These options are available via our API, and will be available for UI users soon. 

Options

1. LaunchAuthExpiry - This specifies how many seconds to keep the launch link valid after the initial launch. The default is "43200" (seconds).

2. LaunchAuthSlidingExpiry - Very similar to expiry except for this uses a sliding window approach. Therefore every time the verification occurs, the expiry time resets to "now + slidingExpiry seconds". Sliding expiry is disabled by default and has a minimum value of 60 seconds when enabled.

3. LaunchAuthFingerprint - This is a boolean that tells whether or not to check the user's browser fingerprint when authenticating. When the launch link is first visited, we'll capture the user's browser fingerprint and check it each time another piece of content is loaded. This ensures that a launch link cannot be used in a different browser or on another device. The user would need to receive a new launch link for their registration on the other device. Defaults to "false". 

4. LaunchAuthIpAddress - This is a boolean that tells whether or not to check the user's browser IP address when authenticating. When the launch link is first visited, we'll capture the user's IP address and check it each time another piece of content is loaded. Defaults to "true".

Destination Level

There are two ways to change the authentication type at the destination level. The first is through the UI. You can find the dropdown to change the content auth type by clicking:

1. The Dispatch tab

2. Click Destinations

3. Click the Destination Name

4. Click Edit

5. Select "Content Vault" from the dropdown under "Launch Authentication." and Save

Currently, enabling content vault via the UI defaults to a 12 hour expiry with IP address checking enabled. The fingerprint and sliding expiry options are disabled by default.

The other option is to use the API calling setDestination with a launchAuth type of "VAULT". Here you can also specify the extra options mentioned above if you want to set them for this destination.

Building a Launch Link

You can also specify the launch authentication type when calling buildRegistrationLaunchLink. You can specify which type of launch authentication you want to use—"COOKIES" or "VAULT"—and then provide extra options if you choose "VAULT." SCORM Cloud will then use that authentication method for that launch.

Example:

const launchLinkSchema = {
    redirectOnExitUrl: 'https://www.somedomain/',
    launchAuth: {
        type: 'vault'
     }
}

Alternatively, you have the option to set Content Vault Authentication at the application level. This would make it so you don't have to specify the launchAuth parameter in your calls to buildRegistrationLaunchLink, as the authentication method would be inherited from the application level. If you have interest in this, you can set that by using the setApplicationConfiguration endpoint with the following body:

{
    "settingId": "LaunchAuthType",
    "value": "vault",
}

 

Information on a possible error stemming from setting Content Vault due to not being able to validate the Learner IP address and fix here.

As always, if you have any questions or concerns, feel free to reach out to support@rusticisoftware.com