BC-7811 - refactor getSignedUrl to use storageProviderId and bucket

[bergatco]

Description

When trying to access files, the used storageProvider is chosen based on the school ID of the creator. If the creator is assigned to another school, after having created the file, the file can no longer be accessed, as the storage of the newly assigned school is used.

Links to Tickets or other pull requests

JIRA :
https://ticketsystem.dbildungscloud.de/browse/BC-7811
https://ticketsystem.dbildungscloud.de/browse/SVS-376
https://ticketsystem.dbildungscloud.de/browse/JHD-47434

Deployments :
https://bc-7811-request-to-files-calls-for-wrong-s3.dbc.dbildungscloud.dev/
https://bc-7811-request-to-files-calls-for-wrong-s3.brb.dbildungscloud.dev/
https://bc-7811-request-to-files-calls-for-wrong-s3.nbc.dbildungscloud.dev/

Changes

Datasecurity

Deployment

New Repos, NPM pakages or vendor scripts

Approval for review

• DEV: If api was changed - generate-client:server was executed in vue frontend and changes were tested and put in a PR with the same branch name.
• QA: In addition to review, the code has been manually tested (if manual testing is possible)
• All points were discussed with the ticket creator, support-team or product owner. The code upholds all quality guidelines from the PR-template.

Notice: Please remove the WIP label if the PR is ready to review, otherwise nobody will review it.

[uidp]

Looks good. I'm still wondering though why prepareSecurityCheck doesn't have to be awaited in fileStorageService.create(). Or is the order of execution not important?

schulcloud-server/src/services/fileStorage/proxy-service.js

Line 270 in 7307043

prepareSecurityCheck(file, creatorId, strategy).catch(asyncErrorHandler);

[bergatco]

Looks good. I'm still wondering though why prepareSecurityCheck doesn't have to be awaited in fileStorageService.create(). Or is the order of execution not important?

schulcloud-server/src/services/fileStorage/proxy-service.js

Line 270 in 7307043

prepareSecurityCheck(file, creatorId, strategy).catch(asyncErrorHandler);

I think any issues with prepareThumbnailGeneration as well as prepareSecurityCheck should be catched / handled by asyncErrorHandler function. Therefore it is not necessary to await both functions.

I just took prepareSecurityCheck as a template while refactoring prepareThumbnailGeneration and aligned both implementations.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud