Serving static assets (disorganized thoughts)

[ormsbee]

Jotting down some quick thoughts for better writeup later:

In #31, we discuss some details of how we can safely upload and serve static assets.

Some high level requirements:

• Permissions
• Trust
• Scale

Auth options:

• cookies?
  • can do at path level, so on per-learning-package basis. But do we need more granularity than that (individual component permissions, e.g. can't see the diagram of a question before it's open)
• permissions should ideally be pluggable.
• querystring for auth-restricted assets?
• if we did this, we'd need to make it time-limited, so things couldn't be passed around

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:

• do we have a generic view that everyone uses (and generates links to)?
• or maybe a generic view that openedx-learning provides but that other apps can import and extend with permissions checks?
• this would be ideal if we didn't have the problem that we have to serve it from a different domain (where none of the auth stuff will work)

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

[ormsbee]

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.

[ormsbee]

Er... unless the signed part is part of the path prefix... which would be... weird... but... maybe feasible?

[ormsbee]

Okay, so after stewing on this a little bit, I'm leaning towards a solution where openedx-learning implements:

1. A DRF APIView subclass that will stream the static asset.
2. Another view class for the really scalable version where we just send enough info to the CDN to have it stream data direct from S3 (for later).
3. Another view class for setting whatever cookie token is going to identify the user (maybe our typical JWT?).
4. A middleware that will make sure that these views will only ever served on the asset domain (not Studio or the LMS), and that no other Studio and LMS views will be served on the asset domain.

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.

[ormsbee]

See https://github.com/openedx/openedx-learning/blob/main/docs/decisions/0015-serving-static-assets.rst