Allow users to export files from workspace

[manhinli]

The current state of workspace already has a download file endpoint; however the way it works is slightly problematic:

• it's a GET request (which is fine by itself)
• you need the Authorization header (also fine by itself and is used for security purposes)
• it generates a temporary URL that should link to the object store and redirects (HTTP 302 with Location header) the request immediately

Normally we would do GET requests for fetching files just by telling browsers to navigate to a URL, however since we need the Authorization header we would need to send the request through XHR (we have axios doing that.)

This however is a problem because browsers also follow redirects and this leads to it rejecting the whole request because the response directs the user agent to another host which violates CORS rules.

Probably need to revisit how we want users to download their files (e.g. changing the way the workspace endpoint operates.)

[gweis]

CORS headers should be set in swift now. (adding that to workspace backend as well)

[manhinli]

I believe this is still an issue:

• The redirect still occurs, but browsers still fire off an OPTIONS request as part of it because it still tries to submit the Authorization header to the redirected URL, and that triggers a CORS check due to it no longer being a "simple" request, and
• The Nectar object store doesn't seem to like OPTIONS requests and returns 401 Unauthorized for them for some reason...
  • The URL that it tries to fire the OPTIONS request is still a functioning temporary URL and I can access the resource fine if I manually copy and load it myself

[gweis]

That's a bit of an unexpected behaviour. I didn't think that it would pass the Authorization header on to the redirected URL as well. The GET request to swift should not include any Authorization headers at all. (It's an external system which should not see that token in any case). Could it be that the axis request interceptor (https://github.com/ausecocloud/workspace-ui/blob/master/src/api/workspace.js#L26)is adding it or is this normal browser behaviour?

If we can't avoid sending the Authorization header, then our only chance is to change the API, and return a 204 or so with a Location header and do the redirect manually.

[manhinli]

Could it be that the axis request interceptor (https://github.com/ausecocloud/workspace-ui/blob/master/src/api/workspace.js#L26)is adding it or is this normal browser behaviour?

Yes, the inclusion of the Authorization header in the API call is what the browser carries forward when it is redirected by workspace to the swift object store.

This appears to be known browser behaviour with other people facing the same issue and finding no real resolution, so we will need to change the API to no longer redirect so that we can use it in the browser.

Alternatives:

• As you mentioned, put URL in some header but serve a different type of response that is not a redirect
  • Should work, though CORS might still be annoying when attempting to read the response headers in the client browser because the use of the Authorization header automatically makes it a non-"simple" request and CORS rules limits what headers can be read from a response
  • If that were to be the case then we would need to whitelist the header in Access-Control-Expose-Headers
• Deliver URL in the response body as text, JSON, etc.

[manhinli]

A new endpoint was created by @gweis today to allow the generated resource URL to be delivered to the client through the response body rather than through a redirect which we can't control. https://github.com/ausecocloud/workspace/commit/84c989e33ccd32700978a5e25b1c4aa1001a8fa5

Basically this resolves the issue and I'm about the finish off the downloading feature.

A point that was raised after the creation of the new endpoint was that we need to have cache controls over the content, otherwise clients may end up retrieving the same URL that was previously generated and may have already expired. This should be small fix by adding headers.

[manhinli]

I believe there may still be outstanding issues with workspace returning generated resource URLs which are invalid by the time the user receives the URL, and it does not appear to be a client caching issue because the URLs are different in my limited testing.

Haven't filed a separate issue as were still in discussions about what to do regarding caching and we might pick it up there.

[manhinli]

There doesn't seem to be issues with the file export feature at the moment and it's already deployed on production systems.