Authorization for downloads

[artlowel]

Currently you have to provide a bearer token in a header to do anything that requires authorization on the rest api, including downloads

That's a problem because when you're logged in and you click a link for a bitstream that isn't public, but you are permitted to download, you'll get an authentication error. The browser doesn't send that header with the download request automatically, and I haven't found a way to set it manually.

The only option you seem to have when working with a header is to download the file with an ajax request to a javascript object, and once it's complete, prompt the user with a save dialog to store it on their computer.

This has a number of disadvantages: It means the browser's regular download UI isn't used, so if you want to show progress you have to implement it in javascript. But the biggest problem is that when you do it with a javascript call the entire file needs to be stored in memory as it's being downloaded.

As I was looking for how people have solved this issue in the past, an approach that came back a number of times was to add an endpoint to the rest api that can use the existing header based authentication to generate a token that's only valid for a few seconds. That token can then be passed as a GET parameter when downloading something.

So the in the UI, when you click a link to download a private bitstream, the client would first call that new endpoint to generate a short lived token, then add that token to the download URL and redirect the user to that URL. The rest api would use the token in the GET param to verify the user's authorization and return the file.

Here are two articles that go in to more detail about the issue and the token aproach

• https://codeburst.io/part-1-jwt-to-authenticate-downloadable-files-at-client-8e0b979c9ac1
• https://medium.com/@gaurav5430/web-security-file-downloads-behind-auth-c38c4cb1842b

[abollini]

I agree, with the proposed approach. The first step should be to create the REST Contract to generate this short living token to use as request param

[tdonohue]

For now, I've tentatively added this to beta3 in the spreadsheet, currently line 62. It may be moved to a later beta though depending on interest & beta3 schedule.

As noted in today's meeting, this needs estimation for the REST API portion (along with the contract as noted by Andrea), and then estimation for requesting & passing that token from the UI.

[artlowel]

Now that the rest contract is merged: here's a spec and an estimate on how to use it in the UI:

• Create a service for the short lived tokens
  • it shoudn't be a dataservice,
  • it should have a single method to retrieve a token
  • It should check if you're authenticated first
• Remove the contents of fileSerice.downloadFile and replace it with a method that
  • calls the new service for a token
  • upon receiving it: use UrlCombiner to add it to the download url
  • set window.location.href to the new url
• Verify that this works for downloads in the submission
• Remove objects, methods and imports that were used for the old downloadFile and are no longer necessary
• Create a component for download links: just the <a> tag
• when not authenticated it should render a link using href, for accessibility
• when you are authenticated it should add an onClick handler that will call fileService.downloadFile and always return false (so the href can still be used to show the url on hover but won't work)
• Replace bitstream download links in all templates for simple and full item pages for all entities with the new component
• update tests and docs

This will take an estimated 6 hours

[tdonohue]

Thanks for the estimate, @artlowel . That looks/sounds good to me!