Pending Imports UI potentially referencing incorrect path for STIX bundles when APP__BASE_PATH is set

[gbikram]

Description

We have been troubleshooting an issue with the ImportDocument connector where it appears that the connector is generating Pending Files with no content (0 size). Upon examining the backend, we noted that the connector is successfully parsing the given files (PDFs, TXTs) and creating the STIX bundles, but the front-end for the Pending Files (dashboard/import/pending/<base64>) is referencing an incorrect URL path i.e <hostname>/storage/view/import... instead of <hostname>/<APP__BASE_PATH>/storage/view... (OpenCTI is running behind a reverse proxy such that the front-end is accessed via the following URL syntax - http://<hostname>/opencti with the APP__BASE_PATH variable). We did note that line 491 in PendingFileContent.js does not seem to be prepending the base path variable to the request and could be a possible cause.

Environment

1. OS 5.15.65-1-Manjaro Linux (PoC)
2. OpenCTI version: OpenCTI 5.3.17
3. OpenCTI client: frontend
4. Other environment details: APP__BASE_PATH configured as /opencti

Reproducible Steps

1. Set APP__BASE_PATH to /opencti
2. Try running the ImportDocument connector on an uploaded file.

Expected Output

The UI for Pending Files should request the generated STIX bundle (JSON file) by taking into account the APP__BASE_PATH for the OpenCTI server (if set).

Actual Output

The generated Pending File entry does not have any of the parsed data listed within the frontend.

Additional information

Slack Chat: https://filigran-community.slack.com/archives/CHZC2D38C/p1665599203378459
Video attached to Slack Chat for reference

[kmcmahon1959]

This seems to have not made it into the 5.4.0 release. Note also: I can't find the module in the main code base. Importing a Stix document, when APP__BASE_PATH is set, still fails. I think this change belongs in /opencti-platform/opencti-front/src/private/components/common/files/workbench/WorkbenchFileContent.js. I hacked my local copy -- inside the container, and then made a new image from that to fix the problem temporarily.

[richard-julien]

Hi @kmcmahon1959 , thanks for the report.
Fixed and will be available in the 5.4.1