Generalizing assets_proxy for all assets #87
Assignees
Comments
Danyal-Faheem
added a commit
to edly-io/openedx-scorm-xblock
that referenced
this issue
Nov 6, 2024
We do this so that custom storage does not need to be defined for Scorm The default storage configured for Open edX should work out of the box with scorm now This also fixes an issue of X-Frame-Options on the LMS when running in development mode closes overhangio#87
Danyal-Faheem
added a commit
to edly-io/openedx-scorm-xblock
that referenced
this issue
Nov 6, 2024
We do this so that custom storage does not need to be defined for Scorm The default storage configured for Open edX should work out of the box with scorm now This also fixes an issue of X-Frame-Options on the LMS when running in development mode closes overhangio#87
|
Hey @timmc-edx, thanks for this enhancement request. I've created a PR in #91 for this. Can you take a look and let me know what you think? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While reading through the code in v18.0.2, I notice that the assets_proxy method currently generates a URL and then reads from it. It looks like this was added to support private S3 buckets. I'm wondering if it could be changed to instead just call the
open()method on the storage (and by always generating asset-proxy URLs for all storages, not just S3.) I think it would have the following benefits:urlmethod override entirely) and make all storages work the same way (lower cognitive overhead)./media/...) are not covered by the X-Frame-Options exemption that the XBlock handler currently enjoys. (This currently makes SCORM xblocks break in devstack.)Is this a change that would make sense? Am I missing something about the APIs and constraints?
The text was updated successfully, but these errors were encountered: