JWT service worker feedback

[LukasKalbertodt]

An issue to collect experiences with the service worker used to auth static files via JWT (see config auth.auth_static_files).

[LukasKalbertodt]

Happened just now: I opened a test deployment in Firefox. The initial load was slow (i.e. graphql took a long time to respond). And then all images were broken. Dev tools showed:

The console said sth along the lines of "load failed because service worker replied with some error to respondWith" or something. Sadly I accidentally cleared the console output.

Refreshing the page normally didn't work. Once I selected "disable cache" in the network tab, a refresh fixed it.

---

Edit: it happened again and now I copied the console output:

Failed to load ‘https://tobira-test-oc.ethz.ch/static/mh_default_org/engage-player/5cd3dfb9-d1fe-4533-93b2-5d7120859554/b42455d6-f39c-4a99-a777-e7b2329c0c88/8c97a5e1-840a-42c8-a59d-f76081dbf90c_3.000s-player.jpg’. A ServiceWorker passed a promise to FetchEvent.respondWith() that rejected with ‘TypeError: NetworkError when attempting to fetch resource.’.

Again, hard reload fixed it.

---

Edit 2:

I managed to catch this problem in Chrome where the dev tools show more useful info. Of particular interest is this:

Access to fetch at 'https://tobira-test-oc.ethz.ch/static/mh_default_org/engage-player/c60eb5b3-eb7c-4efd-976f-0c0ccb6004f3/3c0a55f5-8371-4855-bc5b-ca015bc83cfd/chicken_60fps_x264_1080p_1_000s_player.jpg' from origin 'https://pr1588.tobira.opencast.org' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'https://tobira.opencast.org' that is not equal to the supplied origin. Have the server send the header with a valid value.

But checking the network tab, the preflight request for that file has the correct access-control-allow-origin: https://pr1588.tobira.opencast.org value. The actual request does not show any headers in the network tab and is marked as "CORS error".

My theory is now this: the browsers do actually cache the main request for the image, including the access-control-allow-origin response header. So all our machinery works correctly, then chrome sends the preflight request, which is also correct, but then uses the cached request where it suddenly notices that the header has the wrong origin.

Not sure if this is intended behavior. Maybe it makes sense that the cache entry must not be used for that other origin due to security concerns, but then I would expect the page to just request the file instead of erroring?

I have not confirmed that this is the issue for sure, but it would make sense with everything I observed about it (e.g. disabling cache fixing it). It's still unclear how much this would affect real deployments. The issue only arises here because different origins request the same resource via service workers. This is not typically something happening with production systems?

In terms of what we can do: my gut feeling is that this is a browser (or spec?) bug, but I'm not sure enough about this to open a ticket somewhere. On our side, we can add the option to use a jwt query parameter instead of sending it via Authorization header. That would side step the whole CORS issue, but would disable caching of images completely.

---

Edit 4:

I just found this article explaining that the server should set the Vary header if the access-control-allow-origin header is dependent on the Origin incoming header. That seems to fix it! Will of course have to look at this a few days at least to make sure that was it, but yes, that would be a good simple fix. Will also add it to octoka then I guess.

Including a Vary header ensures that responses are separately cached based on the headers listed in the Vary field.