Custom storage for SCORM Xblock

[naumanshafi]

PR Description

Summary: Implement a custom storage solution to store and retrieve data from a private S3 bucket. Modify the handling of SCORM content requests loaded via JavaScript from a primary file, ensuring they are routed through a custom XBlock view instead of directly accessing the S3 storage. All SCORM XBlock resource requests should be intercepted by the custom view to add signatures before forwarding them to the S3 storage, allowing secure access to private content. Additionally, the ability to read SCORM content from a private bucket should be configurable via Django settings.

Changes Made:

• Created a custom storage implementation to facilitate data storage in a private S3 bucket.
• Implemented a custom XBlock view to handle SCORM content requests.
• Modified the routing of SCORM XBlock resource requests to pass through the custom view for signature addition.
• Added configuration options in Django settings to control the reading of SCORM content from a private bucket.

Motivation: This PR addresses EDE-2041, the Jira issue discussing the need for secure storage and retrieval of SCORM content. By leveraging a private S3 bucket and introducing a custom XBlock view, we ensure that SCORM content requests are processed securely with the addition of signatures. The configurable settings enable flexibility in managing access to SCORM content stored in private buckets.

Additional Notes:

• The custom storage solution follows best practices for secure data handling and authentication.
• The custom XBlock view integrates seamlessly into the existing SCORM content loading process.
• The provided Django settings allow for easy configuration of the SCORM content retrieval from private buckets.

Related Issues

• EDE-2041: Discusses the need for secure storage and handling of SCORM content.

Configuration Changes (lms/envs/private.py and cms/envs/private.py)

# XBlock settings for ScormXBlock
XBLOCK_SETTINGS["ScormXBlock"] = {
    "STORAGE_FUNC": "openedxscorm.storage.scorm_storage",
    "SCORM_S3_BUCKET_NAME": "<your-bucket-name>"
}

[ziafazal]

Hi @regisb could you please review this one?

[naumanshafi]

I acknowledge the concerns you raised. If large files are fetched using the current approach, it could indeed lead to memory issues on the server. However, if we switch to issuing a 302 redirect, it would expose the signed URL in the network tab of the user's browser, which can lead to potential security risks.

Additionally, another challenge arises when serving HTML files that include relative links. After a 302 redirect, the base URL changes to the S3 bucket's URL, so the relative links within the HTML file will fail to load the resources as expected.

[naumanshafi]

I understand the confusion here. but in this scenario, runtime is typically associated with an XBlock instance, not the storage class. Therefore, it is difficult to make the runtime.handler_url method was available in S3ScormStorage.

[regisb]

I understand the confusion here. but in this scenario, runtime is typically associated with an XBlock instance, not the storage class. Therefore, it is difficult to make the runtime.handler_url method was available in S3ScormStorage.

Right. But notice that the storage instance is created by the scorm_storage function, which does take the xblock as a first argument. Thus, the object can be passed to the storage class constructor.

What I am trying to avoid here is to add s3-specific code to the core.

[naumanshafi]

Thank you for your thorough review and feedback on the PR. I have made all the requested changes and addressed the concerns raised. I kindly request you to review the PR again to ensure that the modifications meet the requirements and address your feedback appropriately.

[regisb]

In the future @naumanshafi please reply to each comment in its dedicated thread. If you put all your answers in the main conversation it makes it very difficult to track what was the initial question.