Downloading restricted bitstreams does not work when opening a new tab/window

[tdonohue]

Describe the bug

This issue was previously described in #924, but has reappeared (or perhaps was never fully solved)

When attempting to download an access restricted bitstream in a new tab/window, you will ALWAYS see a 401 "Whitelabel Error Page". If you look at the backend logs, you'll see something like this (notice the 403 on the /shortlivedtokens endpoint followed by the 401 which is returned to the user)

2022-09-02 16:34:58,058 INFO  109b29a1-ab54-41b1-9ad3-3367a846504a 14181de8-5060-43df-aac4-0902b2689d7b org.dspace.app.r
est.utils.DSpaceAPIRequestLoggingFilter @ Before request [GET /server/api/authn/shortlivedtokens] originated from /bitst
reams/56279468-a4af-40e0-a6dc-71324803fa38/download
2022-09-02 16:34:58,060 WARN  109b29a1-ab54-41b1-9ad3-3367a846504a 14181de8-5060-43df-aac4-0902b2689d7b org.dspace.app.r
est.exception.DSpaceApiExceptionControllerAdvice @ Access is denied (status:403 exception: Requests to this endpoint sho
uld be made from a trusted IP address. at: org.dspace.app.rest.AuthenticationRestController.shortLivedTokenViaGet(Authen
ticationRestController.java:232))
2022-09-02 16:34:58,269 INFO  unknown fdcf354a-d940-47c9-8731-0e9ad02f95d0 org.dspace.app.rest.utils.DSpaceAPIRequestLog
gingFilter @ Before request [GET /server/api/core/bitstreams/56279468-a4af-40e0-a6dc-71324803fa38/content] originated fr
om https://tim-dspace.loca.lt/
2022-09-02 16:34:58,293 WARN  unknown fdcf354a-d940-47c9-8731-0e9ad02f95d0 org.dspace.app.rest.exception.DSpaceApiExcept
ionControllerAdvice @ Authentication is required (status:401 exception: Access is denied at: org.springframework.securit
y.access.vote.AffirmativeBased.decide(AffirmativeBased.java:73))

To Reproduce

This issue appears to ONLY be reproducible on a public, "production" site. It doesn't seem to be reproducible when running the frontend on http://localhost:4000 ... likely because localhost is considered a "trusted IP" so that the above /shortlivedtoken request succeeds.

However, it is reproducible on https://demo7.dspace.org. It is also possible to reproduce it locally if you run the UI (and backend) behind a public proxy (like https://localtunnel.me) and then access the UI via that proxy URL.

There are several ways to reproduce this error in the UI:

1. One way is via the Submission/Workflow process.
   • Simply create a new submission & upload a file. Then attempt to download the file you just uploaded (from the submission form). You'll receive this 401 error as the download is opened in a new tab. This bug is also described in DSpace 7 file download error during submission and workflow DSpace#8378
2. Another way is to create an Item with an access restricted bitstream. Then authenticate into DSpace, copy the bitstream download URL and paste it into a new tab (or Ctrl + Click the bitstream should open it in a new tab). You'll receive the same 401 error.
3. A third way is to download an access-restricted PDF. Click the back button in your browser and you'll see this same 401 error. This bug is described in PDF file download problem #1743

These three issues all appear to be related to the same problem, that it's currently not possible to download restricted bitstreams in a new tab.

Expected behavior
Assuming you have an active authenticated session, it should be possible to download bitstreams in a new tab. We even have code to support this via the isBlank flag in the file-download-link.component.ts. However, this isBlank flag only works for non-restricted bitstreams.

Related work
Related directly to DSpace/DSpace#8378 and #1743 . Fixing this bug would likely fix both of those tickets as well.

[tdonohue]

@artlowel & @benbosman : You or your team may be interested in this ticket, as it directly relates to past work that Atmire did in #1004 and DSpace/DSpace#3223. It appears those PRs either didn't fully fix this issue (previously reported as #924), or something new has since broken the functionality.

I've flagged it as high priority for 7.4 as it seems to be the root cause behind several other reported bugs (see description above). I'll admit, I have not yet been able to determine if the core problem is in the UI codebase or the REST API codebase (or both). But, this issue seems to be affecting people in Production (see the discussion in DSpace/DSpace#8378 as an example) and is also easily reproducible on https://demo7.dspace.org.

[tdonohue]

@benbosman : This is an older ticket that was previously assigned to you / your team to investigate. I wanted to verify that this is something you are able to work on for 7.5? If not, I'll unassign and look for a different volunteer.

[benbosman]

We've done a more detailed analysis on this, and I've updated the ticket with our estimate

[tdonohue]

@benbosman : Thanks for verifying you are working on this & for adding the estimate. This looks good to me.