File Upload fails if authentication token is refreshed while on submission form (401Unauthorized error)

[MoeBen23]

Description

Hi,

Some of our users have reported encountering errors when uploading files after a certain period of time. Specifically, the DSpace client displays an “Error Loading File” message once the JWT token is renewed by the front-end client.

This issue arises when a user’s submission process exceeds 30 minutes. The front-end client renews the token 2 minutes before session timeout; however, it does not use the new token if the user attempts to upload files after the renewal.

We are currently using DSpace 7.6.2. Could you provide any insights or recommendations on resolving this issue?

Thanks.

Steps to Reproduce

Steps to reproduce the behavior:

1. Log in to DSpace using local authentication.
2. Start a new submission.
3. Upload files periodically (e.g., every few minutes). Initially, all uploads succeed.
4. The DSpace client automatically renews the JWT token via a server call to the /login endpoint.
5. After the token renewal, any subsequent file upload attempts fail with a 401 Unauthorized error.

Expected behavior

The JWT token timeout is set to 30 minutes. By default, the client renews the token 2 minutes before expiration. Once the new token is received, it should be used for all subsequent file uploads without failure.

Observed Issue

Currently, file uploads continue to use the expired token instead of the newly issued one.
On failed upload requests, the Bearer token in the request header differs from the token stored in the cookie, indicating a mismatch.

Screenshots:

In the screenshot below, I monitored network traffic using Google Chrome Developer Tools

Image1: Three uploads were done successfully

Image 2: DSpace renews the token. This happens 2 min before it expires.

Image 3: All uploads attempts fail after the token renewal. I attempted to upload two files.

Image 4: The failed upload request contains a different token in the header compared to the one in the cookie. It uses the old one in the header, and the new one in the cookie.

[bram-atmire]

Hi @MoeBen23 Thank you for reporting this!!! I think we may have to tackle this in the Angular front end codebase instead of here, but I already wanted to share here what I found:

It seems we're already defending against the xsrf tokens expiring, but not the JWT tokens in

https://github.com/DSpace/dspace-angular/blob/dspace-7_x/src/app/shared/upload/uploader/uploader.component.ts#L137C1-L150C6

One suggestion could be something along the lines of:

this.uploader.onBeforeUploadItem = (item: any) => {
    const latestJwt = this.authService.getToken(); // Fetch the latest JWT token
    if (latestJwt) {
        item.headers.push({ name: 'Authorization', value: `Bearer ${latestJwt}` });
    }
};

[MoeBen23]

Thanks @bram-atmire . That’s great! It took me a while to reproduce this issue. Would you recommend re-creating it in the Angular front-end issue repository so it can potentially be included in an upcoming patch?

[tdonohue]

Moving this ticket to dspace-angular as I also think this is frontend bug. Needs a volunteer to investigate a solution and/or create a PR (@bram-atmire if you or someone from Atmire have found a solution, please feel free to create a PR).