In the world of e-learning, SCORM (Sharable Content Object Reference Model) is a crucial standard that allows for the interoperability and tracking of online learning content. However, when it comes to hosting SCORM packages, particularly with the use of cloud services like Amazon S3 and CloudFront, several technical challenges arise. One major issue is related to cross-domain policies which can affect the functionality of SCORM packages when they attempt to access the parent window object.
In this blog post, we’ll walk through how to effectively serve SCORM packages from Amazon S3 and CloudFront to Moodle while addressing these cross-domain challenges. I will share the steps taken to ensure smooth integration .
The Challenge
SCORM packages are designed to work within a single domain due to security constraints imposed by browsers. When a SCORM package tries to communicate with the Moodle LMS, it often needs to interact with the parent window. This interaction can fail if the content is served from a different domain due to cross-origin resource sharing (CORS) issues.
- host it anywhere but make sure that domain is same.
- This can be achieved in two ways
- Keep on same server under same document root
- Keep somewhere else
- In any case, challenge is to keep this for authenticated audience
Possible solution :
- Use another moodle system to server scorm Exposing through LTI. In this case you need an active Moodle setup with all resource required to run Moodle
- Host it somewhere else and hide it through reverse proxy
We will expore 2nd part, Hosting scorm packages on S3 and serveing through reverse proxy
Solution Overview
1. Creating an S3 Bucket and Configuring CloudFront
Firstly, we created an Amazon S3 bucket to store the SCORM packages.
Steps:
- Created an S3 bucket and uploaded SCORM packages.
- Configured CloudFront with the S3 bucket as its origin.
- Ensured that CloudFront was set up to only serve files through an Origin Access Control (OAC) to secure access.
2. Setting Up a CloudFront Distribution
A CloudFront distribution was created to serve files from the S3 bucket.
Steps:
- Created a CloudFront distribution with the S3 bucket as the origin.
- Configured caching behavior and performance settings as needed.
3. Applying Web Application Firewall (WAF) Rules
To control access and enhance security, we applied a Web Application Firewall (WAF) to the CloudFront distribution. WAF rules were set up to allow access to the SCORM content while blocking unauthorized requests.
Steps:
- Set up a WAF with rules to allow access from specific IP ranges or referrer headers.
- Configured rules to block common security threats.
Implementing a Reverse Proxy on Moodle
Since the SCORM content needs to interact with the Moodle LMS, we set up a reverse proxy on the Moodle Apache server. This proxy rewrites requests to route through the CloudFront URL, making it appear as if the SCORM content is being served from the same domain.
Steps:
- Configured Apache to act as a reverse proxy.
- Set up URL rewriting rules to direct SCORM requests to the CloudFront distribution
<LocationMatch "/s3scorm">
ProxyPass http://dl098adhd79.cloudfront.net
ProxyPassReverse http://dl098adhd79.cloudfront.net
Header add x-from "developerck.com"
RequestHeader set x-from "developerck.com"
</LocationMatch>
url of manifest file would be
https://develoeprck.com/s3scorm/<foldername at s3>/imsmanifest.xml
Configuring Custom Moodle Cookie Name
To maintain session integrity and ensure that Moodle can correctly track user interactions with the SCORM content, we configured a custom Moodle cookie name. This allows Moodle to recognize and manage sessions even when the content is served through a different domain.
Steps:
- Configured Moodle to use a custom cookie name for sessions.
- Ensured the cookie name was consistent across requests and aligned with the CloudFront distribution setup.
- You can add following under config.php
$CFG->sessioncookie = ‘< anything >’;
— Make sure same is added under WAF
— also make sure under moodle that siteadmin has enbale scormsetting
Enable external package typescorm | allowtypeexternal
Conclusion
By following the above steps, we successfully addressed the cross-domain issues associated with SCORM packages and leveraged CloudFront’s bandwidth benefits. Hosting SCORM packages on Amazon S3 and serving them through CloudFront allows for efficient content delivery while maintaining the necessary domain alignment for functionality.
Feel free to share your thoughts or questions about SCORM integration or cloud-based content delivery in the comments below!