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:
Remove code from the S3 backend (remove the url method override entirely) and make all storages work the same way (lower cognitive overhead).
Possibly, make it possible to use any Django storage without any modification at all.
Allow serving local files via the asset proxy, which would help avoid the issue where the default storage's URLs (/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?
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:url
method 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?