Closed ormsbee closed 7 months ago
Quick note to self: signed links don't allow us to support static assets with relative links to each other, e.g. JS referencing images and other JS files. So we need to do some cookie based solution.
Er... unless the signed part is part of the path prefix... which would be... weird... but... maybe feasible?
Okay, so after stewing on this a little bit, I'm leaning towards a solution where openedx-learning implements:
APIView
subclass that will stream the static asset.So the idea would be that content_libraries
would subclass the view and set it up with the permissions callbacks that it wants, with one being a function that checks to see if they have course author/staff access to the library. But later on, something similar on the LMS side of things could look up whether the user is allowed to see the individual XBlock that the asset is a part of.
Jotting down some quick thoughts for better writeup later:
In https://github.com/openedx/openedx-learning/pull/31, we discuss some details of how we can safely upload and serve static assets.
Some high level requirements:
Auth options:
So maybe what we need is to make one cookie for the browser to use that encodes their user information in a signed/secure way, and then we let libraries (or anything else) extend an openedx-learning view with permissions info... which sounds like "LMS causes the browser to POST to an endpoint on the asset domain which sets the JWT, and then all files are requested using that JWT."
Views:
URL structure:
Specific version:
/{learning_package_key}/{component_key}/v20/static/images/fig1.png
Draft/Published?
/{learning_package_key}/{component_key}/draft/static/images/fig1.png
/{learning_package_key}/{component_key}/published/static/images/fig1.png
-